Yes, and...
I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X
*are* what people usually mean when they say SHOULD. In the spirit of Say What
You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the
author to turn the statement into the if Y then MUST X or if Z then MUST NOT X
form. Being pedantic and pedagogic:
SHOULD send a 1 UNLESS you receive a 0
really means
UNLESS you receive a 0, one MUST send a 1.
My vision of the UNLESS clause is not necessarily a protocol state, but an
environment state. These are things that I can see fit the SHOULD/UNLESS form:
SHOULD send a 1 UNLESS you are in a walled garden
SHOULD flip bit 27 UNLESS you have a disk
SHOULD NOT explode UNLESS you are a bomb
are all reasonable SHOULD-level statements.
I would offer that ANY construction of SHOULD without an UNLESS is a MAY.
Unless of course one considers us the Protocol Nanny's(tm) - if do not do a
SHOULD, we will send you to bed without your treacle! I.e., there IS NO
DISTINCTION BETWEEN A BARE SHOULD AND A MAY.
On Aug 29, 2011, at 9:47 PM, ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com wrote:
Hi -
From: "Eric Burger" <eburger-l(_at_)standardstrack(_dot_)com>
To: "Narten Thomas" <narten(_at_)us(_dot_)ibm(_dot_)com>; "Saint-Andre
Peter" <stpeter(_at_)stpeter(_dot_)im>
Cc: "IETF discussion list" <ietf(_at_)ietf(_dot_)org>
Sent: Monday, August 29, 2011 3:08 PM
Subject: Re: 2119bis
I would assume in the text of the document. This paragraph is simply an
enumeration of Burger's Axiom:
For every SHOULD, there must be an UNLESS, otherwise the SHOULD is a MAY.
I disagree.
I concur with your disagreement. SHOULD should *not* be used when the
list of exceptions is known and practically enumerable.
If the "UNLESS" cases can be fully enumerated, then
"SHOULD x UNLESS y" is equivalent to "WHEN NOT y MUST X."
(Both beg the question of whether we would need to spell out that
"WHEN y MUST NOT X" is not necessarily an appropriate inference.)
RFC 2119 SHOULD is appropriate when the "UNLESS" cases are
known (or suspected) to exist, but it is not practical to exhaustively
identify them all.
Let's not gild this lily.
+1
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf