![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
My additional comment is that if there is some case I can think of that leads me to say "should", there might also be another that I didn't think of. Asking me to detail them all up front is IMHO asking too much. On the other hand, I wouldn't be at all bothered by being told that I had to justify a "must" - since in my mind it is something to be used when not doing the action has a predictable negative outcome, asking the author to say what that predictable negative outcome would be is reasonable.
My bottom line on a "should" is that if an implementer doesn't do what the specification says he "should", he should have a good reason and be prepared to explain it if questioned (for example by a customer or during an interoperability test). "I disagreed with the spec" is *not* a good reason, although it might be a good reason to implement it and provide a configuration knob that turned that functionality off, whatever it was.
On Jun 25, 2008, at 8:24 PM, John C Klensin wrote:
--On Wednesday, 25 June, 2008 07:59 -0400 Scott Brim <swb at employees.org> wrote:On 6/25/08 5:37 AM, Fred Baker allegedly wrote:On Jun 25, 2008, at 5:28 AM, Frank Ellermann wrote:A SHOULD X unless Y essentially means "SHOULD (X or Y)"I'd read it as "do X, but if you have a very good excuse not doing X might do. One known very good excuse is Y."That is more or less my definition of "should". I say something "must" be so when I can tell you an operational failure that would or could happen if it isn't. If I would like to say "must" but can think of a case in which it would not be appropriate I say "should", and am saying that if it is not so in someone's implementation they should be prepared to say what their reason was.... and draft authors should include explanations in their drafts of the reasons an implementor might legitimately have for not implementing the "should". For example, an older operating system that does not support a new capability.Scott, In principle, sure. But I note that you use a lower-case "should" in the first sentence above and that, like the incremental promotion of "these are available" to "MUST unless you receive a dispensation", this could easily be turned into a firm requirement by someone who was being zealous about rule-making. Do you really mean, e.g., ... where feasible and, in the author's judgment, appropriate, it is desirable to include explanations or illustrations of the exception cases in drafts that use SHOULD. ??? I've run into a number of situations over the years in which there are known edge cases that prevent a MUST but where those edge cases are rare and obscure enough that describing them would require extensive text... text that might indirectly end up providing guidance for bad behavior. For those situations, I'd prefer to see something like: In all of the common cases, the system SHOULD... Rather than The system SHOULD do A unless Y, in which case B SHOULD be done unless Z, in which case C SHOULD be done where each of X, Z, B, and C, might require a half-page explanation. That btw is part of the difficult with some of the discussion in this thread. The discussion has, as I've read it, concentrated on SHOULD do A unless Y and SHOULD do A but may do B where it would often be useful to say SHOULD do A unless Y and then SHOULD do B Note that the latter can often be rewritten as a MUST, e.g., MUST do A unless condition Y occurs, in which case MUST do B I believe that good sense and discretion are important here. I also believe that attempts to map case-by-case good sense into rules generally gets us into trouble and that such efforts should be examined carefully by the community. In addition, as Frank has noted, negative statements and words are often used quite differently than they are in English by languages that are otherwise reasonably similar to English. That calls for use of extreme care in use of negative statements in conformance clauses, a subject on which I would hope the RFC Editor (as well as authors and the IESG) would be very sensitive. john _______________________________________________ IETF mailing list IETF at ietf.org https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ IETF mailing list IETF at ietf.org https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.