I know that for us, if the name of the header were to change at this
late time, we would *NOT* be able to change our implementation to match
for probably another 6-12 months.
So personally, here's a -1 for making such a change at this time.
Tony Hansen
tony(_at_)att(_dot_)com
Murray S. Kucherawy wrote:
An issue has been raised regarding the name of the proposed header
field. Some of the methods supported by the draft are specifically
message authorization and not authentication (e.g. SPF, Sender-ID) and
there's a concern that this might mislead some consumers of the header
field's contents. Do others concur, or is it not something about which
to be concerned?
Because of the existing installed base of code doing this work,
splitting the header field into two (one for authentication and one for
authorization) seems like it would work but something easier could be done.
Perhaps we could take advantage of a lexical coincidence and rename it
to "Auth-Results", specifying in the draft that it covers both
authentication results and authorization results. Would that work?
Are there other suggestions?
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html