fwiw -
I have, for many SIPits (a rather large interop event for SIP
implementations) worked to get the people writing code from these
documents to understand that MUST means MUST and SHOULD means MUST ...
(very long pause)... unless you _really_ know that not following the
SHOULD won't result in very bad things.
They typically respond with MUST means MUST unless they're sure they
can get away without it most of the time, and that SHOULD means its in
some future release that will get funding maybe someday. Some of that
response is tongue-in-cheek - some of it isn't.
I see a strong trend for unadorned SHOULDs to remain unimplemented.
SHOULDs that have a very clear, and explicitly called out even when
they seem incredibly obvious, explanation of the bad things that can
happen if you don't follow them get implemented.
So, at least for the documents I edit, I work really hard to explain
the SHOULDs to help motivate the implementors to actually build things
that conform to it.
RjS
On Jun 25, 2008, at 12:02 PM, Scott Brim wrote:
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
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf