Re: SHOULD vs MUST

--On Wednesday, 25 June, 2008 13:02 -0400 Scott Brim
<swb@employees.org> wrote:

> On 6/25/08 8:24 AM, John C Klensin allegedly wrote:
>> 
>> --On Wednesday, 25 June, 2008 07:59 -0400 Scott Brim
>> <swb@employees.org> wrote:
>>> ... 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.
> 
> 
>> 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.
> 
> My rule of thumb is: when you're writing the draft if
> something is not a MUST, ask yourself "why not?" and write
> down your answer.  You can be brief but make it clear that the
> SHOULD is a MUST with exceptions.
> 
> There's no way we should have strict process rules about this.
> The IETF has enough rules as it is.  However, explanations of
> SHOULDs do make better standards.  The point is to give
> guidance to implementors.  I did an informal survey last year
> and found that some implementors treat every SHOULD as a MUST,
> but more of them just treat a SHOULD as a MAY, essentially to
> be ignored.  An explanation of the circumstances surrounding a
> SHOULD will lead to a lot more consistency in implementation.
> Many SHOULDs in RFCs are because there are old implementations
> that need to be taken into account, or because some capability
> isn't widely possible yet but will be within the lifetime of
> the standard.  If a MUST becomes a SHOULD to take that into
> account, and you explain it, your chances of getting rid of
> non-MUST-capable implementations eventually goes up
> tremendously.  So, to reiterate, when you're writing the draft
> if something is not a MUST, ask yourself "why not?" and write
> down your answer.

Certainly we are in complete agreement about the principles
here.  We probably also agree about Fred's slightly different
take, which is thinking about whether a proposed MUST really
might have exception cases that we would prefer to keep within
the bounds of the standard.  My concern is about anything that
might get turned into another rule while various of us are
trying to concentrate on technical work and not, e.g., watching
every entry in the IESG's tracker logs.

More generally, thinking carefully about these conformance
statements is A Good Thing and should be encouraged whenever
possible.

   john

> 
> 

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf