e.g.
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" are appropriate
when valid exceptions to a general requirement are known to exist or appear to
exist, and it is infeasible or impractical to enumerate all of them.
However, they should not be interpreted as permitting implementors to fail to
implement the general requirement when such failure would result in
interoperability failure.
On Aug 30, 2011, at 11:46 AM, Eric Burger wrote:
I think you have hit the root cause on the head.
I would also offer that by removing the crutch, or raising the bar to using
the crutch, will help alleviate the root cause.
On Aug 30, 2011, at 11:44 AM, Keith Moore wrote:
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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf