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

Loa Andersson <> Tue, 29 March 2016 11:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A33012D6D1; Tue, 29 Mar 2016 04:30:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cjTBISNyqv6H; Tue, 29 Mar 2016 04:30:20 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB54E12D6D3; Tue, 29 Mar 2016 04:30:07 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 3ABBD1802A51; Tue, 29 Mar 2016 13:30:03 +0200 (CEST)
To: Scott Bradner <>, Barry Leiba <>
References: <> <> <> <> <> <> <> <20160328104731.GO88304@verdi> <> <20160328132859.GP88304@verdi> <> <> <> <> <> <>
From: Loa Andersson <>
Message-ID: <>
Date: Tue, 29 Mar 2016 19:29:56 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Approved-At: Tue, 29 Mar 2016 09:38:06 -0700
Cc: "Heather Flanagan (RFC Series Editor)" <>, "" <>, IESG <>, IETF discussion list <>
Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words]
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Mar 2016 11:30:22 -0000

2nd in motion


On 2016-03-29 19:27, Scott Bradner wrote:
> 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 <> 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
>> <> 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 <> 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