On 5/19/11 12:50 PM, Murray S. Kucherawy wrote:
Can anyone remember why there's a SHOULD for the downgrade to 7-bit in
RFC4871 Section 5.3, rather than a MUST? The likelihood of breakage
is so high when sending 8-bit data that DKIM almost becomes pointless
without the upgrade.
Not advocating for this to be changed in --bis (yet), but someone's
asking me for the history behind that decision.
I can't speak directly to the history of why the WG *thought* they were
putting in the SHOULD, but Michael, Wietse, Scott, and Hector seemed to
have missed the point of why the SHOULD is absolutely appropriate:
In RFC 2119 (the document that defines MUST, SHOULD, etc.), "MUST" does
not mean "vitally important" and "SHOULD" does not mean "really really
important, but less important than MUST". "MUST" means "you have to do
this or you're not going to interoperate." "SHOULD" means, "there are
ways to not do this which will still interoperate, but you had better
know what those ways are and you better be sure to do them, and if you
don't, then you MUST NOT do this." That is, "SHOULD" is equivalent to
"MUST unless you know exactly what you are doing."
In this case, the spec says that you MUST downgrade prior to signing
*unless you know that the end-to-end path is 8-bit clean and will not
downgrade later*. That's what SHOULD downgrade means. If there is an
implementation that doesn't downgrade and sends a message without
knowing that the path is end-to-end 8-bit clean, then it is in violation
of the spec. Changing it to MUST doesn't change anything for such an
implementation; it is already in full violation.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html