Dave CROCKER wrote:
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.
Quite clear from what it actually says:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
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.
Please refrain from passing the buck to the WG. The document editors are:
D. Crocker (editor)
Tony Hansen (editor)
M. Kucherawy (editor)
If the WG was technically incapable as you are implying, then the
*onus* was on the editors to make sure it was writing it correctly.
The problem in the WG was key cogs not following the charter,
introducing deliberate out of scope concepts, mixing up the functional
requirements with the technical specifications, doing global word
replacements and not seeing if it was correct, removing/adding
semantics and not seeing it fit the functional goals, confusing
synergism with past or concurrent document productions, lost of WG
interest participation with a resultant Consensus by Osmosis process,
and frankly, all of which, all reflected a mark of poor leadership.
In this case (8BIT Downgrades), it is my view the SHOULD language is
fine and was quite fitting the understood technical feasibility realities.
--
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