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@xxxxxxxxxxxxxxxxx wrote: >> Hi - > >>> From: "Eric Burger" <eburger-l@xxxxxxxxxxxxxxxxxx> >>> To: "Narten Thomas" <narten@xxxxxxxxxx>; "Saint-Andre Peter" <stpeter@xxxxxxxxxx> >>> Cc: "IETF discussion list" <ietf@xxxxxxxx> >>> 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf
<<attachment: smime.p7s>>
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf