Re: SHOULD vs MUST

[Scott Brim <[e-mail]>]

On 6/25/08 8:24 AM, John C Klensin allegedly wrote:
> 
> --On Wednesday, 25 June, 2008 07:59 -0400 Scott Brim
> <[e-mail]> 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.


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