Barry, While I don't think our position are far apart, I'm not sure I agree, partially because of the concern I (and Stewart) tried to express earlier about perfectd foresight and enumerating all possible cases. Now, if every statement of the sort you suggest came with an additional clause equivalent to "unless you run into a case that we didn't anticipate at all", it would end up fairly close to what I suggested. More generally, I think the IETF and its predecessors have always -- both before and after we started using the term "standard" regularly -- been a bit ambivalent and conflicted about clear conformance statements. Some of that ambivalence, IMO, comes from the differences between trying to write specs for implementers who want to work together in good faith to produce interoperable implementations, using those specs for guidance versus writing specs for regulators and contract-enforcers who are concerned about specifications that can identify implementations that try to cut corners or offer variations to gain, e.g., competitive advantage. I remember some discussions very early on, long before OSI turned into a poster child for the other point of view, about how it was better to reach agreements on a design or protocol, document it mostly for the reference of those who agreed and those who might follow in their footsteps, and then move on rather than spending weeks, months, or longer trying to pin down every possible detail. I vaguely even remember a Padlipsky rant or two on the subject. To some extent, the Robustness Principle came out of that thinking too: we might more precisely restate at least part of the intent today, in far more words, as "if you are not very confident you know what the spec intended and that others will read it the same way you do, then be conservative in what you send..." So, I think that, unless we have reached the stage where we want and expect our specifications to cover every detail and be exact about it, SHOULD serves real value... but only if we require explanations of why it is present rather than using it as "MUST, but maybe not" or "MUST unless you don't feel like it". best, john --On Friday, February 11, 2022 11:34 -0500 Barry Leiba <barryleiba@xxxxxxxxxxxx> wrote: > I agree with what Scott, Michael, and John have said, and > agree with Scott that we should not have "SHOULD", but it's > too late to change that. The sense that "SHOULD" is really > there for would be adequately covered by "MUST" with an > explicit escape clause documented: "You MUST do this unless > <escape explicitly specified>." > > For example, "You MUST include the exact length value unless > computing it is so time-consuming that it would be likely to > exceed client timeout periods." (In contrast to "You MUST > include the exact length value even if it is time-consuming to > compute." And even better, "You MUST include the exact length > value unless computing it is so time-consuming that it would > be likely to exceed client timeout periods. Clients rely on > the length value <for purpose>, and inaccurate length values > can cause <these types of problems>." > > Our specs would be much better if we made every effort to > specify SHOULD conditions that way instead.
