100%? That is extreme. I hope you are not stating giving two interfacing points, one end will read a SHOULD as a MUST? I hope not. One end point expecting a MUST behavior from a SHOULD recommendation is seriously broken especially if it doesn't get what it expects. That is not a matter of opinion - the system will break down if end points read a SHOULD as a MUST for one basic reason:
Backward Compatibility Any implementator who reads SHOULD as a MUST implement and expects all standard software, old and new, to be working as if was a MUST is in trouble. I think you know that Pete. But lets going over this: First, an ESMTP server is not required to support 8BITMIME, therefore there can not be any DKIM expectation nor a MUST requirement for the ESMTP server to be even ready do any sort of 8BIT downgrades. It would be incorrect for DKIM to assume it can force this ESMTP extension on the SMTP server. Second, even if the payload is accepted for a time-shifted isolated, plug and play DKIM signing component, RFC4671 section 5.3 clearly states it is out of scope: Such conversion is outside the scope of DKIM; the actual message SHOULD be converted to 7-bit MIME by an MUA or MSA prior to presentation to the DKIM So I don't even know why we are talking about this. If its out of scope how we can contemplate a MUST here. I concur with Levine, take it out. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Pete Resnick wrote: > On 5/19/11 6:52 PM, Hector Santos wrote: >> 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. >> > > This is 100% incorrect, and if a WG were to produce a document where it > assumed the above definition of SHOULD, the chair should immediately put > the brakes on, because it should get bounced by the IETF Last Call and > the IESG Review. SHOULD has a singular meaning in IETF Standards Track > documents which cite RFC 2119, and it is stated quite clearly in section > 3 and section 6 of that document. If anyone is using it differently, > they need to go back and re-read RFC 2119 *very* carefully. This is not > a matter of opinion. Implementations very much depend on the RFC 2119 > definitions of these terms and this document had better as well. > > pr > -- 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