[ietf-dkim] 8bit downgrades

[Pete Resnick]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20110519/91ec96c6/attachment.html