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.
My impression is that the 2119 limitation on MUST and SHOULD for
only necessary protocol features is sometimes forgotten.
--
Bill McQuillan <McQuilWP(_at_)pobox(_dot_)com>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf