Eliot Lear wrote:
Dave CROCKER wrote:
Generally, the changes dealt with:
Sorry, forgot an important item:
3. Changed section 6.3 and Appendix D references to be to SDID (d=)
Since the new consensus appears to be that i= has semantics that are entirely
undefined, it does not seem possible that the wg would advise showing it to an
end user.
Further to my earlier message about clarifying the interoperability
problem, if the above statement is really the case, why not remove i=
entirely? We are already rather strongly warned about its use in RFC
4871. So, what is its remaining value?
While i= is currently optional, when it is present its value must meet
certain requirements, that the "domain part" MUST be the same as or
(normally) a subdomain of the d= value. Removing mention of i= in the
spec would imply that an i= with an arbitrary value could be added,
which would create interoperability problems with current
implementations that enforce the present wording. I believe that
enforcement was even a part of the interoperability tests some time
back.
Just remember that i= is optional, and leave it at that.
-Jim
|
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html