Pete Resnick wrote: > 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, it isn't that complicated: MUST is a "throw in your face" requirement - don't follow, expect things to break and not match up with your peers - shame on you - a bug. SHOULD is an optional requirement - Its a recommendation for the better, but things will not break things for your peers if you don't follow it. You may be shamed but the person shaming you is the one wrong if they depended on a SHOULD operation as a MUST and his software broke. SHOULD is appropriate here IMV because it approves things (for DKIM), but it can't be enforced for common sense historical reasons. Primarily, it can't enforce change. Going to 8-bit MIME was an expensive and complex endeavor and now asking people they should downgrade and worst, tamper with passthru mail is hard to swallow. In fact, I may even support a change to a MAY, simple because there is a natural expectation for non-tampering passthru mail and more and more systems are using 8 bit communications. The problem isn't 8bit, the problem is DKIM and this topic is yet another example of the many WG contradictions. Before we attempt to force change for the sake of DKIM verification, it might be a good idea to renew our focus on the serious repercussions for the already existing relaxations and marginally errors we have accepted for DKIM verification failures If we change this downgrade to a MUST, then we must also fix the C14N problem we forgot about the extra <CRLF> possible at the top the message possible in IETF streams like IETF-SMTP. Can't have it both ways: its important here, but not there. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html