--On Wednesday, 25 June, 2008 13:02 -0400 Scott Brim
<swb(_at_)employees(_dot_)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(_at_)employees(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf