Re: SHOULD vs MUST

[Fred Baker <[e-mail]>]

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
> <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf