On 8/30/11, Murray S. Kucherawy <msk(_at_)cloudmark(_dot_)com> wrote:
Mark Nottingham:
1) I agree that the "SHOULD... UNLESS" pattern ought be documented.
I had never thought of this before. I kind of like the idea, especially
since SHOULD
has always meant "MUST unless you really know what you're doing"
Such an odd reading. Does it mean you MUST because you could not
handle it otherwise?
It takes two to tango. One side reasons can be different than the
other. If a software breaks down because it read SHOULD as a MUST and
expected the other end will also view is a MUST, then it didn't know
what it was doing. Things break down. Implementors on either side
can't depend on it and need to function in lieu of it. There is always
the possibility one decided "Nahhhh, not needed, not worth the cost.
Its not required." etc, and no one should die because of that
decision.
I think it MUST be noted that a Minimum Implementation for a protocol
is all anyone can expect. If a SHOULD item is among the listed minimum
requirements, it MUST be removed from the list or changed to a MUST.
Maybe the term Minimum Implementation (is part of, is not part of) can
be incorporated into each of the key word text.
--
hls
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf