RE: Fuzzy words [was Uppercase question for RFC2119 words]
Eric Gray <eric.gray@ericsson.com> Mon, 28 March 2016 20:27 UTC
Return-Path: <eric.gray@ericsson.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD7B12D19B; Mon, 28 Mar 2016 13:27:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSKmlUxycqIC; Mon, 28 Mar 2016 13:27:23 -0700 (PDT)
Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C3A112D1B0; Mon, 28 Mar 2016 13:27:18 -0700 (PDT)
X-AuditID: c6180641-f79fa6d0000057a9-15-56f993810c81
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id C9.C3.22441.18399F65; Mon, 28 Mar 2016 22:26:42 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Mon, 28 Mar 2016 16:27:17 -0400
From: Eric Gray <eric.gray@ericsson.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "Scott O. Bradner" <sob@sobco.com>, Barry Leiba <barryleiba@computer.org>
Subject: RE: Fuzzy words [was Uppercase question for RFC2119 words]
Thread-Topic: Fuzzy words [was Uppercase question for RFC2119 words]
Thread-Index: AQHRiSw33A+4lBlJ1EWj5YxJCPJ3Tp9vRxEQ
Date: Mon, 28 Mar 2016 20:27:15 +0000
Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF644AC2AFC@eusaamb107.ericsson.se>
References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <CA+9kkMCsT43ZCSdq8gdKXu1k4pJgbf0ab5tE=dDiFfrTT2gtkA@mail.gmail.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <CALaySJ+hYMMsKE7Ws-NJbyqH55E-mQM-duTEcJGc0TWvTP88Ew@mail.gmail.com> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <CALaySJJkNj2jfm0gJpuDzq8oFDjTNn-uQ5MHdmEOLwTiFZUyQQ@mail.gmail.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com>
In-Reply-To: <56F98CD1.10706@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.9]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyuXRPiG7T5J9hBqvDLQ4tvsRq0XZxH5PF jD8TmS2ebZzPYnH7mZXF2n/t7BbHO5Ud2D1aVvUye+ycdZfdY8mSn0weDW3HWD1eHPjGHMAa xWWTkpqTWZZapG+XwJVx9uB3poIvthVTt69naWBcYdPFyMkhIWAicanxGSuELSZx4d56ti5G Lg4hgaOMEi/+dLFDOMsZJQ492McOUsUmoCFx7M5aRpCEiEADo8TbuZPBHGaBJYwSU/ZfYQKp EhZwlvjwaR4LiC0i4CKxcsNpKNtIYs/GbrB9LAKqEscmXWYDsXkFfCW2TlsCtfs7q8TcJb+Z QRKcAuoS5xc9AVvNCHTg91NrwBYwC4hL3HoynwnicAGJJXvOM0PYohIvH/+DekhRYl//dKBe DqB6TYn1u/QhWhUlpnQ/ZIfYKyhxcuYTlgmMYrOQTJ2F0DELSccsJB0LGFlWMXKUFhfk5KYb GW5iBMbcMQk2xx2Me3s9DzEKcDAq8fA+CP8RJsSaWFZcmXuIUYKDWUmEd92kn2FCvCmJlVWp RfnxRaU5qcWHGKU5WJTEeb99vBwmJJCeWJKanZpakFoEk2Xi4JRqYFz0MffuxZKGWX5hgoxr 3FgfZWkutj/QK8gUs+6Js+LxdS3lD9ZZ/9uf+Wdqs1oaS0d4Jnvwp/6jQhMMPv/TZPytyPbD 703qJrYIGW/Buts1DVO//C6bPXFXSe+aKbw1884XflAw8BPJ/j9Fuklq56SJVjMmF384aCf5 UVjpR8Lqu5FxXmqH1JRYijMSDbWYi4oTAVyu75i1AgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/hUXn-zGfUsQ9LghcPsaSUxFLnto>
Cc: "Heather Flanagan (RFC Series Editor)" <rse@rfc-editor.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>, IETF discussion list <ietf@ietf.org>, IESG <iesg@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Mar 2016 20:27:25 -0000
Brian, I agree with most of what you say. My impression has been that many times the use of some of the fuzzier words stems from the fact that the author(s) have occasionally forgotten that they are writing a specification, and not a bit of literary prose. Using variation in wording does not make a specification more readable, as it might a piece of literature. It makes it less readable, even if it might make it a less boring read. I am not certain that making a specification exciting enough to keep the average reader awake is a goal. One area where I do slightly disagree is in your characterization of the use of must verses MUST, and similar words. The English usage of the word "must" can vary slightly from the normative use of the word "MUST." As an example - in the statement "what goes up, must come down" - the word "must" is almost certainly meant to reflect a fact of nature, as opposed to an implementation choice that is needed if we want to have interoperable implementations of a specification. If you could throw a ball into the air, and it just hung there, I'm not sure we should refer to it as "non-compliant." :-) Also, a statement along the lines of "electronic equipment MUST have a power source of some sort" is not particularly useful for interoperability - even though it seems likely to be true. Nor do I think we would want an implementation that did not have this limitation to be deemed non-compliant. There are similar uses for "need" for instance. And - while I cannot think of an example at the moment - I am not prepared to bet the farm that there are no such similar uses for "required." Maybe this might be the case for a legal requirement that has nothing to do with compatible implementation? In any case, it is occasionally necessary to use these terms in an explanatory sense, having not very much to do with specification of normative behavior. The good news is that most of us can tell if the meaning is explanatory, verses normative. -- Eric -----Original Message----- From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Monday, March 28, 2016 3:58 PM To: Scott O. Bradner; Barry Leiba Cc: Heather Flanagan (RFC Series Editor); rtcweb@ietf.org; IETF discussion list; IESG Subject: Fuzzy words [was Uppercase question for RFC2119 words] 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@computer.org> 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 > >
- Uppercase question for RFC2119 words John Leslie
- Re: Uppercase question for RFC2119 words Scott O. Bradner
- Re: Uppercase question for RFC2119 words Barry Leiba
- Re: Uppercase question for RFC2119 words Scott O. Bradner
- Re: Uppercase question for RFC2119 words John C Klensin
- Re: Uppercase question for RFC2119 words Barry Leiba
- Fuzzy words [was Uppercase question for RFC2119 w… Brian E Carpenter
- RE: Fuzzy words [was Uppercase question for RFC21… Eric Gray
- Re: Fuzzy words [was Uppercase question for RFC21… Barry Leiba
- Re: Uppercase question for RFC2119 words John Levine
- Re: Uppercase question for RFC2119 words David Farmer
- Re: Uppercase question for RFC2119 words Dick Franks
- Re: Uppercase question for RFC2119 words S Moonesamy
- Re: Fuzzy words [was Uppercase question for RFC21… Tony Finch
- Re: Fuzzy words [was Uppercase question for RFC21… Scott Bradner
- Re: Fuzzy words [was Uppercase question for RFC21… Loa Andersson
- Re: Fuzzy words [was Uppercase question for RFC21… Randy Bush
- Re: Fuzzy words [was Uppercase question for RFC21… John C Klensin
- Re: Fuzzy words [was Uppercase question for RFC21… Scott Bradner
- Re: Fuzzy words [was Uppercase question for RFC21… Ben Campbell
- Re: Fuzzy words [was Uppercase question for RFC21… Dave Cridland
- Re: Fuzzy words [was Uppercase question for RFC21… John C Klensin
- Re: Fuzzy words [was Uppercase question for RFC21… Heather Flanagan (RFC Series Editor)
- Re: Fuzzy words [was Uppercase question for RFC21… HANSEN, TONY L
- Re: Fuzzy words [was Uppercase question for RFC21… John C Klensin
- Re: Fuzzy words [was Uppercase question for RFC21… Dave Cridland
- Re: Fuzzy words [was Uppercase question for RFC21… HANSEN, TONY L
- Re: Fuzzy words [was Uppercase question for RFC21… John C Klensin
- Re: Fuzzy words [was Uppercase question for RFC21… Eliot Lear
- Re: Fuzzy words [was Uppercase question for RFC21… Brian E Carpenter
- Re: Fuzzy words [was Uppercase question for RFC21… Scott O. Bradner
- Re: Fuzzy words [was Uppercase question for RFC21… Brian E Carpenter
- Re: Fuzzy words [was Uppercase question for RFC21… Brian E Carpenter
- Re: Fuzzy words [was Uppercase question for RFC21… Dave Cridland
- Re: Uppercase question for RFC2119 words Adam Roach
- Re: [rtcweb] Uppercase question for RFC2119 words Dave Crocker
- Re: [rtcweb] Uppercase question for RFC2119 words Adam Roach
- Re: [rtcweb] Uppercase question for RFC2119 words Eliot Lear
- Re: Uppercase question for RFC2119 words Lee Howard
- Re: [rtcweb] Uppercase question for RFC2119 words Ben Campbell
- Re: Uppercase question for RFC2119 words Warren Kumari
- Re: [rtcweb] Uppercase question for RFC2119 words Dave Cridland
- Re: [rtcweb] Uppercase question for RFC2119 words Adam Roach
- Re: [rtcweb] Uppercase question for RFC2119 words Dave Crocker
- Re: [rtcweb] Uppercase question for RFC2119 words John C Klensin
- Re: [rtcweb] Uppercase question for RFC2119 words Pat Thaler
- Re: [rtcweb] Uppercase question for RFC2119 words Ole Jacobsen
- Re: [rtcweb] Uppercase question for RFC2119 words Barry Leiba
- Re: [rtcweb] Uppercase question for RFC2119 words Stephan Wenger
- Re: [rtcweb] Uppercase question for RFC2119 words Dave Cridland
- Re: [rtcweb] Uppercase question for RFC2119 words Mark Andrews
- RE: [rtcweb] Uppercase question for RFC2119 words Drage, Keith (Nokia - GB)
- RE: [rtcweb] Fuzzy words [was Uppercase question … Drage, Keith (Nokia - GB)
- Re: [rtcweb] Uppercase question for RFC2119 words tom p.
- Re: [rtcweb] Uppercase question for RFC2119 words Lee Howard
- Re: Fuzzy words [was Uppercase question for RFC21… Abdussalam Baryun
- Re: Uppercase question for RFC2119 words Francis Dupont