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+i...@mauve.mrochek.com wrote:
>> Hi -
>
>>> From: "Eric Burger" <eburge...@standardstrack.com>
>>> To: "Narten Thomas" <nar...@us.ibm.com>; "Saint-Andre Peter"
>>> <stpe...@stpeter.im>
>>> Cc: "IETF discussion list" <ietf@ietf.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@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
