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

Reply via email to