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