On 5/19/2011 10:50 AM, 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?

To concur with one of the lines of explanation that has been offered:

      It is generally a good idea to refrain from mandating something that adds 
cost without benefit.  The recommendation is for a bit of additional processing 
-- the conversion -- that is not /always/ necessary, because downgrading does 
not always happen.

      If the signer has no knowledge of the path that the message will travel 
-- 
as, indeed, is /currently/ true for nearly all signers -- then they have to use 
the safest choice, namely performing the conversion, to increase the 
survivability of the signature, in case the path does happen to mess with the 
data in the way being discussed.

There are existing scenarios in which the signer well might know that the extra 
processing is /not/ required, such as for internal mail.  This might not be 
common, but it is legitimate.  The same applies for the emergence of 
8-bit-clean 
environments, as has been mentioned.

The concept that there will at least be islands of 8-bit clean is not all that 
silly and has been driving the latest round of EAI work.  That sort of concept 
certainly does tend to be viewed more optimistically by proponents than history 
would advise, but there are reasonable indicators to suggest that it's not an 
entirely silly idea with respect to MIME and email transit.  So, again, for 
such 
environments, the extra protection of the processing specified as SHOULD would 
be wasteful. This is why SHOULD is the correct choice and MUST is not.



> On 5/19/2011 2:53 PM, Pete Resnick wrote:
>> 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."

Correct, of course, and nicely said.

This confusion about the meaning of normative language is one of the useful 
touchstones to some of the problems that have plagued the DKIM working group.

Among folks who haven't read the relevant bit of RFC 2119, the confusion isn't 
surprising.  However one would think that anyone with extended participation in 
a working group would do the homework of learning the basics of essential 
specification vocabulary, such as the meaning of normative language or at least 
the difference between relaying and forwarding.

The fact that erroneous definitions persist among among some who actually have 
read RFC 2119 suggests possible issues with reading comprehension, since the 
RFC 
language about this is rather simple, direct and clear.



On 5/19/2011 7:20 PM, John Levine wrote:
 > I think Pete's analysis is correct, but my advice would be to take
 > it out altogether.  We don't have any great insight into the warts
 > of what paths are likely to downcode a message and what paths aren't,
 > so I would prefer not to purport to offer advice about it.

The SHOULD being discussed actually represents an important bit of responsible 
specification writing.  It MUST be retained.

First, it is necessary for the reason I described above:  It specifies 
something 
that adds cost, but there are legitimate scenarios that do not need it AND 
there 
is reason to believe the need will reduce over time.  If the signer knows it is 
not needed, then it is entirely wasteful to do the processing.

Second, a protocol specification SHOULD help the reader understand something of 
the usage dynamics of a protocol.  What are some of the interesting scenarios 
that can cause problems and what is the way to deal with them?  If a scenario 
has sufficiently severe effects and is plausibly going to happen, then the 
method of dealing with the situation is best specified normatively.

It is generally not a good idea to leave a protocol implementer guessing what 
situations to worry about and guessing about how to deal with them.



> On 5/22/2011 1:39 AM, Michael Deutschmann wrote:
>> One suggestion for compromise, from another "outsider" (myself):

While it's always good to see efforts at compromise, in this case, there is no 
need:  The current language fits the current situation nicely..


>> Specify MUST, but clarify that this is just for now and may be revisited
>> at a later time

This would miss the fact that there are existing scenarios that do not require 
the extra mechanism and there are already efforts ongoing that will make is 
/less/ useful.  To gain extremely widespread deployment, those efforts will 
need 
a very long time, of course, but nonetheless, they are happening.


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Reply via email to