On Aug 30, 2011, at 12:07 PM, Bill McQuillan wrote:
On Tue, 2011-08-30, Keith Moore wrote:
But in general I get the impression that people are attacking
SHOULD because of specific problems rather than general
problems. Since I find SHOULD very useful, to me it makes more
sense to try to outline cases where SHOULD is problematic, and
provide advice for those cases, than to try to get rid of it or change what
it means.
e.g. For the specific case of optional features that must be
negotiated, I don't think that SHOULD is the problem. Rather I
think that optional features are too common. That's not to say
that optional features and feature negotiation are never
useful, particularly when extending a protocol that is already
well-established in the field. But if making features optional
is seen by WGs as a way to avoid making hard decisions about
what is required to interoperate, that really is a problem. It
just doesn't have anything to do with SHOULD.
How about recommending SHOULD ... BECAUSE to encourage the author
to justify the SHOULD. I suspect that this would reduce the
number of SHOULDs, that would be better as MAYs, due to the
author's personal preference.
I think 1122 and 1123 did this very well. State the general requirement
briefly in terms of MUST or SHOULD or whatever, then follow that by an
explanation written in normal language.
What I see far too often these days is an attempt to write both complicated
requirements and the explanations in terms of 2119 conditional keywords. This
makes the requirements difficult for an implementor to understand and perhaps
more ambiguous than was intended.
My impression is that the 2119 limitation on MUST and SHOULD for
only necessary protocol features is sometimes forgotten.
This is actually one case where I think 2119 misstated things. The problem is
that it's not just protocol features (as viewed on the wire) that matter in
practice. SHOULD and its friends are really useful for cases where you can't
precisely nail down what should happen on every particular platform on which
the protocol might be implemented, but it's quite reasonable to state the
intent.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf