--On Tuesday, February 15, 2022 19:56 -0600 Spencer Dawkins at IETF <spencerdawkins.ietf@xxxxxxxxx> wrote: > I also agree with Barry's note further down in this thread, > but wanted to talk about one of John's points here. > > On Fri, Feb 11, 2022 at 10:14 AM John C Klensin > <john-ietf@xxxxxxx> wrote: > >> >> >> If SHOULD is used, then it must be accompanied by at least one >> of: >> (1) A general description of the character of the >> exceptions and/or in what areas exceptions are likely >> to arise. Examples are fine but, except in plausible >> and rare cases, not enumerated lists. >> (2) A statement about what should be done, or what the >> considerations are, if the "SHOULD" requirement is not >> met. >> (3) A statement about why it is not a MUST. > > > I never understood how a receiver of a packet that did not > satisfy what I might call a "naked SHOULD" (with none of these > coverings) was supposed to know what to do next. > > Since the receiver can't count on the SHOULD requirement being > satisfied, it seems like the least a specification could do, > was to provide guidance about what to do next, as in (2). > > So I think (2) is even more helpful than the helpful (1) and > (3). I think it depends on the protocol. For network protocols near the bottom of the stack, it will often be the case that things either work or they don't and it seems to me that Scott's observation -- which I might restate as "SHOULD is almost never helpful" -- is correct or nearly so and the right answer might be closer to (3) or maybe (1). Closer to the application layer, where interoperation with non-Internet systems may be important, and maybe for Security and other issues, edge cases where things usually work may be more common, it may be less possible to precisely spell out all of the possibilities, and SHOULD (and/or the Robustness Principle) become more useful and possibly necessary, at least if we wish to avoid very long and complex standards. And that said, when I think of the places where I have used SHOULD, far more of them would be best associated with the type of explanation associated with (2) than with the other two cases. best, john
