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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf