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