On 6/25/08 8:24 AM, John C Klensin allegedly wrote:
--On Wednesday, 25 June, 2008 07:59 -0400 Scott Brim
<swb@xxxxxxxxxxxxx> 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
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf