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
