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

Brian E Carpenter <> Tue, 29 March 2016 23:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F42212D57B; Tue, 29 Mar 2016 16:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7rtsx2BnC26T; Tue, 29 Mar 2016 16:39:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5E67A12D0BE; Tue, 29 Mar 2016 16:39:11 -0700 (PDT)
Received: by with SMTP id n5so26736870pfn.2; Tue, 29 Mar 2016 16:39:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=7r9wHYQ8r86b+wwmG3T/CGrRi1ZiTd4SqkLH5FfN/VI=; b=m8Tnkv+9b4pDUeFILU1PADbA6/v5iQF6XOAPoAZXcfOeMwcBLYfJ8wY7zE36TkAdDG eIgGAczQ8HZ5/rEO8eUf5cZcz54C4qcbf15wC+697rL+uDpGZnWT3Llg/A7uHJg6ull2 IEkkZei7WPOeWf1lE+OSLlijivVHQWNOAVzXTi2MuuIV5mkwDOOsfTVaS1snoySmYfnV vRU8bPhhANEnHf0AW+lNEV6eLpbYgSwQRdjVwvUx3Kkk4sC3AGYeWuR/iputffMFh1nn leyy505O4rgF12imjbuZtqUWT6shNV7rIt9wnk8FElAMTz6z0McGbjp8c8nWy4hFri/j hp0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=7r9wHYQ8r86b+wwmG3T/CGrRi1ZiTd4SqkLH5FfN/VI=; b=Qg55O7aaUBXZiV75pB4SOcO8JtY9Drp1Q1TV6SZDWdC7F5s8K5o4tYD30uSR8MhKoo yc41Iphb4XqviDdlpTdahyaUSsm1ZW4img7jo6MxGRC9/akLy7eZgbY8n6apOtud/7AF 69vzAYO0NZ6Q+AONHILyeWlWncQftM8MBrYDP4FY78sZ9wqGA09mc1l/iB6L9gB05G3r PI2ikenPMGObnizZrlu1tnyR8TpgTdIihbw5yJESDi1K0Fugqz0yS0VKmti6EjN91XI/ zuYVjtAfjaCEhIwxISbJrEd3rSO/8N4zW04WvO3YnueB08iicv3quwmhjaMrsLzTrD4V lf+Q==
X-Gm-Message-State: AD7BkJJ+x0laP1GZU965LNkRmZUqw8l/fYeH8ZBhsUB2XfGuZ8d5KvAT1AmXUTfcq/FNCg==
X-Received: by with SMTP id w64mr7804800pfi.154.1459294751426; Tue, 29 Mar 2016 16:39:11 -0700 (PDT)
Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by with ESMTPSA id kw10sm887644pab.0.2016. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2016 16:39:10 -0700 (PDT)
To: Scott Bradner <>, Barry Leiba <>
References: <> <> <> <> <> <> <> <20160328104731.GO88304@verdi> <> <20160328132859.GP88304@verdi> <> <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Wed, 30 Mar 2016 12:39:10 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "Heather Flanagan (RFC Series Editor)" <>, "" <>, IETF discussion list <>, IESG <>
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 23:39:14 -0000

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'?"


> 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