Re: Fuzzy words [was Uppercase question for RFC2119 words]

"Scott O. Bradner" <sob@sobco.com> Tue, 29 March 2016 23:43 UTC

Return-Path: <sob@sobco.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 947ED12D0E0; Tue, 29 Mar 2016 16:43:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.109
X-Spam-Level:
X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 DWtthuFbHoey; Tue, 29 Mar 2016 16:43:05 -0700 (PDT)
Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFBC112D0C7; Tue, 29 Mar 2016 16:43:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 13D391A31DDF; Tue, 29 Mar 2016 19:43:04 -0400 (EDT)
X-Virus-Scanned: amavisd-new at sobco.com
Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yqd6lfzZjgJD; Tue, 29 Mar 2016 19:43:02 -0400 (EDT)
Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 647381A31DCF; Tue, 29 Mar 2016 19:43:02 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Fuzzy words [was Uppercase question for RFC2119 words]
From: "Scott O. Bradner" <sob@sobco.com>
In-Reply-To: <56FB121E.6070900@gmail.com>
Date: Tue, 29 Mar 2016 19:43:01 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <E9A170AB-2EF7-4CD1-9652-24074925DEAB@sobco.com>
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> <CALaySJJ0WTU5m3b6Cad7ULyLHzpWeTpTFpu-y=hHyoYs5xqsXg@mail.gmail.com> <B0FC9E8C-9F20-43D0-904A-31BC19A9C476@sobco.com> <56FB121E.6070900@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/MbX3qpS5Et7wyyD-osLPh14tkj0>
Cc: "Heather Flanagan \(RFC Series Editor\)" <rse@rfc-editor.org>, Barry Leiba <barryleiba@computer.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: Tue, 29 Mar 2016 23:43:06 -0000

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@gmail.com> 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@computer.org> 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@gmail.com> 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@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
>>>>> 
>>>>> 
>>>> 
>> 
>> 
>