On 3/28/16 12:58 PM, Brian E Carpenter 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. I've been watching this thread and am thrilled to see these clarifications coming through. Changes to RFC 2219 are a community decision, not an RFC Editor decision, but the RFC Editor definitely appreciates consistency and clarity! -Heather > 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 >>