fwiw - seems to me that the basic idea that MUST and must are the same is wrong 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 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 >>> >>> >>