Dave Crocker wrote:
The part that is throwing me off is the "support transfer-related" -
this could imply authenticating the channel, or transfer mechanism.
Leaving that out makes it clearer to me. So I guess I would ask what the
"transfer-related" part means - distinguishing this effort from
performing such authentication at the MUA level, perhaps ?
I think we should make it clear in the charter which problem we are
solving, the authenticating the channel, or the message (or both).
That was the intent of:
The MASS working group will produce
specifications that support transfer-related, encryption-based
authentication of an email message and its contents.
"encryption based message contents authentication" seemed pretty clear to me.
Can you suggest some different text that would work better?
I think it would be good to clearly draw the lines here with respect to
That would be outside of the scope of work, per this draft. The draft is for
defining a particular mechanism, not for dealing with the policies of its use or
for defining mechanisms to communicate that policy.
Perhaps that exclusion should be added to the 'out of scope' section of the
It seems that such existing material didn't help with the issues in
MARID. I'm not wanting/suggesting control of people's behavior either,
but is explicitly stating a requirement that output of the group should
meet certain guidelines to be considered satisfactory be out of order ?
I also think we should deal with the IPR issue up front in the charter -
interoperability should be the driving point, so any solution should be
acceptable to open source licenses, IMO.
I do not know what you mean "deal with". The IETF already has extensive
material that covers IPR issues. Beyond that, we have very limited control over
people's actual behavior.