I was about to write something like that to Scott; thanks for making
it unnecessary.
My additional comment is that if there is some case I can think of
that leads me to say "should", there might also be another that I
didn't think of. Asking me to detail them all up front is IMHO asking
too much. On the other hand, I wouldn't be at all bothered by being
told that I had to justify a "must" - since in my mind it is something
to be used when not doing the action has a predictable negative
outcome, asking the author to say what that predictable negative
outcome would be is reasonable.
My bottom line on a "should" is that if an implementer doesn't do what
the specification says he "should", he should have a good reason and
be prepared to explain it if questioned (for example by a customer or
during an interoperability test). "I disagreed with the spec" is *not*
a good reason, although it might be a good reason to implement it and
provide a configuration knob that turned that functionality off,
whatever it was.
On Jun 25, 2008, at 8:24 PM, John C Klensin wrote:
--On Wednesday, 25 June, 2008 07:59 -0400 Scott Brim
<swb@xxxxxxxxxxxxx> wrote:
On 6/25/08 5:37 AM, Fred Baker allegedly wrote:
On Jun 25, 2008, at 5:28 AM, Frank Ellermann wrote:
A SHOULD X unless Y essentially means "SHOULD (X or Y)"
I'd read it as "do X, but if you have a very good excuse
not doing X might do. One known very good excuse is Y."
That is more or less my definition of "should". I say
something "must" be so when I can tell you an operational
failure that would or could happen if it isn't. If I would
like to say "must" but can think of a case in which it would
not be appropriate I say "should", and am saying that if it
is not so in someone's implementation they should be prepared
to say what their reason was.
... and draft authors should include explanations in their
drafts of the reasons an implementor might legitimately have
for not implementing the "should". For example, an older
operating system that does not support a new capability.
Scott,
In principle, sure. But I note that you use a lower-case
"should" in the first sentence above and that, like the
incremental promotion of "these are available" to "MUST unless
you receive a dispensation", this could easily be turned into a
firm requirement by someone who was being zealous about
rule-making.
Do you really mean, e.g.,
... where feasible and, in the author's judgment,
appropriate, it is desirable to include explanations or
illustrations of the exception cases in drafts that use
SHOULD.
???
I've run into a number of situations over the years in which
there are known edge cases that prevent a MUST but where those
edge cases are rare and obscure enough that describing them
would require extensive text... text that might indirectly end
up providing guidance for bad behavior. For those situations,
I'd prefer to see something like:
In all of the common cases, the system SHOULD...
Rather than
The system SHOULD do A
unless Y, in which case B SHOULD be done
unless Z, in which case C SHOULD be done
where each of X, Z, B, and C, might require a half-page
explanation.
That btw is part of the difficult with some of the discussion in
this thread. The discussion has, as I've read it, concentrated
on
SHOULD do A unless Y
and
SHOULD do A but may do B
where it would often be useful to say
SHOULD do A unless Y and then SHOULD do B
Note that the latter can often be rewritten as a MUST, e.g.,
MUST do A unless condition Y occurs, in which case MUST
do B
I believe that good sense and discretion are important here. I
also believe that attempts to map case-by-case good sense into
rules generally gets us into trouble and that such efforts
should be examined carefully by the community.
In addition, as Frank has noted, negative statements and words
are often used quite differently than they are in English by
languages that are otherwise reasonably similar to English.
That calls for use of extreme care in use of negative statements
in conformance clauses, a subject on which I would hope the RFC
Editor (as well as authors and the IESG) would be very sensitive.
john
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf