On 4/1/11 10:01 AM, Hector Santos wrote: > Jim Fenton wrote: > >> I am formally proposing that the i= tag >> and supporting text be removed from 4871bis. >> >> [snip] >> >> In a conversation with Dave Crocker and Murray Kucherawy, they noted >> the use of the local part of i= as an opaque identifier. Its use as >> such an identifier is not described in any standard, but the >> relaxation of the current restrictions on the use of i= (that the >> domain-part be a subdomain of d=, etc.) would result in an >> incompatibility with RFC 4871-compliant verifiers. It is, however, >> possible to remove it entirely without creating a compatibility problem. > > By remove, does that mean implementators can safely begin to not offer > it for Domain signers to use or consider?
I should probably have used the term "deprecate" rather than "remove". That's correct, an implementation compliant with 4871bis would not normally use the i= tag/value in signatures. > > Documenting this stuff to layman operators is HARD especially when we > don't even have a firm grip of its utility or what value it offers. :) That's part of the reason for deprecating the feature: if people don't understand the utility of it, and it is not being used, then it is only adding complexity to the spec. > > If its one more useless thing we don't have to ambiguously document > for customer to understand and use with no real verification payoff, > then +1 to remove i= from DKIM. Thanks. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
