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 ?
sigh. yes. that does tend to confuse folks, and I have not managed to find a
good way to avoid the confusion.
The reason I cite 'transit' is because the fact that the mechanism is used for
the short time of a transfer, and for limited, transit-related authentication,
that the mechanism might permit different technical choices than we need for
longer-term authentication, such as is provided by pgp and s/mime.
As an example, perhaps the keys can be shorter. Perhaps the key
'certification'
can be. Perhaps...
So it is intended to highlight issues that might affect the design, rather than
to specify channel vs. object.
I'd greatly appreciate any suggested text that gets this across better.
>Perhaps that exclusion should be added to the 'out of scope' section of the
>charter?
I think it would be good to clearly draw the lines here with respect to
policy, yes.
good point.
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 ?
Yes, certainly a reasonable desire.
My own reaction is that I wish it would make a difference, but I don't think it
will. I can imagine our spending a lot of time trying to pre-specify those
requirements, but failing to get any community consensus.
In effect, what you are suggesting would require modifying existing IETF
practices on this issue and we won't be doing that.
d/
--
Dave Crocker <mailto:dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <http://brandenburg.com>