+1
I believe the issue is the subtle differences between:
SHOULD for something new, i.e. no dependency
SHOULD for something old, i.e. an enhancement or new dependency
the engineer is trying to push hard.
As much as we want to isolate protocols, in practice, we are
integrating many protocols and in theory, it should all work. I
believe it has for the most part. But increasingly a protocol upgrade
or new protocol here requires a "MUST USAGE" dependency of another
otherwise optional protocol there. I believe that is what we are
seeing with this new interpretation.
New protocol X works better if existing optional (and much older)
protocol Y is applied as a SHOULD. It would like to say MUST but it
can't because Y is already optional and not required. This new
interpretation will make software implementing X non-compliant if it
also doesn't support Y.
---
HLS
On Mon, Aug 29, 2011 at 10:44 PM, Eric Burger
<eburger(_at_)standardstrack(_dot_)com> wrote:
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
hls
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf