yup - it is a change, one that might help against the people that say 2119 MUST be used all the time but it will not address the examples you cite Scott > On Mar 29, 2016, at 7:39 PM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > > On 30/03/2016 00:27, Scott Bradner wrote: >> fwiw - seems to me that the basic idea that MUST and must are the same is wrong > > I disagree, specifically for MUST, SHALL, REQUIRED and NOT. RFC2119 > doesn't change their meanings, because their meanings are categorical > anyway. It's absolutely appropriate that RFC 2119 states their meanings, > but they aren't ambiguous. > >> and will lead to >> even more confusion >> >> imo - any clarification should (not SHOULD - i.e. the english language) say >> 1/ some authors capitalize some words for emphasis and clarity >> 2/ there is no requirement to use capitalized words >> 2/ when capitalized words are used RFC 2119 says what the capitalized words mean >> 3/ non capitalized words are interpreted using normal English > > That is a change, because 2119 does not say point 3/. I'm not saying > it's a bad change, but it really is a change, affecting SHOULD and MAY > in particular. > > Honestly I don't think any of this will change the questions I sometimes > have for authors, basically > "Should that 'should' be 'SHOULD'?" > "Should that 'may/MAY' be 'might'?" > > Brian > >> >> Scott >> >>> On Mar 28, 2016, at 4:30 PM, Barry Leiba <barryleiba@xxxxxxxxxxxx> wrote: >>> >>> Brian, I think your note goes to how important it is to write clearly >>> and to get a lot of eyes on it before we publish it. Well-written >>> documents, with or without 2119 key words, and with or without >>> lower-case look-alikes, can still be clear. Fuzzily written documents >>> will be fuzzy. >>> >>> In particular: >>> >>>> they mean? It can be very unclear. If a node receives a message containing >>>> an element covered in the spec by "allowed" instead of "OPTIONAL", is the >>>> receiver supposed to interoperate or to reject the message? >>> >>> Well, this is where 2119 advises that we *use* the key words when >>> interoperability is at stake. It's fine to be fuzzy when it doesn't >>> matter, though even then, I'd argue for more explanation: >>> >>> Every frobotz MUST contain a valid bleeg. The glorp field in the >>> frobotz is an unsigned integer that is normally between 0 and 666, >>> inclusive. Values greater than 666 are allowed, but recipients >>> using older software might not be able to handle such values. >>> ... >>> When processing a frobotz that does not meet the requirements in >>> section 3.1.4, it is permissible to reject the frobotz outright, or to >>> attempt to process the parts of it that make sense; the choice is >>> an implementation decision. However, any frobotz that does not >>> contain a valid bleeg MUST be rejected. >>> >>> That sort of thing. >>> >>> Barry >>> >>> On Mon, Mar 28, 2016 at 3:58 PM, Brian E Carpenter >>> <brian.e.carpenter@xxxxxxxxx> wrote: >>>> There are times when I think RFC2119 was a really bad idea, despite it having >>>> become probably the most frequently cited RFC (inside and outside the IETF). >>>> It seems to create as much confusion as it avoids. >>>> >>>> There are four words whose RFC2119 meaning is different from the dictionary >>>> meaning: should, recommended, may and optional. Having special typography >>>> for them is useful, because it signals the RFC2119 meanings. But if a spec >>>> uses, for example, a mixture of SHOULD and should, who knows what the authors >>>> intended? To that extent, the proposed clarification is helpful. >>>> >>>> The other words (must, shall, required, not) mean what they always mean. >>>> The only argument for upper-casing them is aesthetic symmetry. If a spec >>>> uses alternatives like mandatory, necessary or forbidden, they are just as >>>> powerful. >>>> >>>> So >>>>> these definitions are only meaningful if the words are capitalized >>>> can be applied to should, recommended, may and optional if we want, >>>> but strictly doesn't apply to must, shall, required, not, mandatory, >>>> necessary, forbidden, need, or any other such words. >>>> >>>> Where we can get into real trouble is if a spec contains should, recommended, >>>> may and optional *plus* other non-categorical (fuzzy) words like ought, >>>> encourage, suggest, can, might, allowed, permit (and I did not pull those >>>> words out of the air, but out of draft-hansen-nonkeywords-non2119). What do >>>> they mean? It can be very unclear. If a node receives a message containing >>>> an element covered in the spec by "allowed" instead of "OPTIONAL", is the >>>> receiver supposed to interoperate or to reject the message? >>>> >>>> If we are issuing guidance, it should probably include a specific warning >>>> to use any such fuzzy words with extreme care. >>>> >>>> Brian >>>> On 29/03/2016 03:13, Scott O. Bradner wrote: >>>>> one minor tweak >>>>> >>>>>> On Mar 28, 2016, at 10:09 AM, Barry Leiba <barryleiba@xxxxxxxxxxxx> wrote: >>>>>> >>>>>>> The wishy washy descriptive rather than proscriptive language in the abstract was because I, >>>>>>> the IESG and the community were not of one mind to say that the use of such capitalized >>>>>>> terms should be mandatory - quite a few people felt that the english language was at >>>>>>> least good enough to convey the writer’s intent without having to aggrandize specific words. >>>>>>> Thus the abstract basically was saying: if you want to use capitalized words here is a standard >>>>>>> way to say what they mean >>>>>> >>>>>> Ah. Then perhaps the clarification needs to go a little further and >>>>>> make this clear: >>>>>> - We're defining specific terms that specifications can use. >>>>>> - These terms are always capitalized when these definitions are used. >>>>> >>>>> these definitions are only meaningful if the words are capitalized >>>>> >>>>>> - You don't have to use them. If you do, they're capitalized and >>>>>> their meanings are as specified here. >>>>>> - There are similar-looking English words that are not capitalized, >>>>>> and they have their normal English meanings; this document has nothing >>>>>> to do with them. >>>>>> >>>>>> ...and I'd like to add one more, because so many people think that >>>>>> text isn't normative unless it has 2119 key words in all caps in it: >>>>>> >>>>>> - Normative text doesn't require the use of these key words. They're >>>>>> used for clarity and consistency when you want that, but lots of >>>>>> normative text doesn't need to use them, and doesn't use them. >>>>>> >>>>>> Barry >>>>> >>>>> >>>> >> >> >