Re: New Version Notification for draft-leiba-rfc2119-update-00.txt

Time Warner Cable <> Wed, 10 August 2016 15:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 874CF12D7F1 for <>; Wed, 10 Aug 2016 08:35:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.127
X-Spam-Status: No, score=-1.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RDNS_NONE=0.793] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KQig6WBw3fGz for <>; Wed, 10 Aug 2016 08:35:19 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id B9A0E12D608 for <>; Wed, 10 Aug 2016 08:35:19 -0700 (PDT)
Received: from ([]) by (8.14.4/8.14.4) with ESMTP id u7AFZECa072716 for <>; Wed, 10 Aug 2016 11:35:14 -0400
Received: (qmail 6267 invoked by uid 0); 10 Aug 2016 15:35:14 -0000
Received: from unknown (HELO ? ( by 0 with ESMTPA; 10 Aug 2016 15:35:14 -0000
User-Agent: Microsoft-MacOutlook/
Date: Wed, 10 Aug 2016 11:35:14 -0400
Subject: Re: New Version Notification for draft-leiba-rfc2119-update-00.txt
From: Time Warner Cable <>
To: Barry Leiba <>, IETF discussion list <>
Message-ID: <>
Thread-Topic: New Version Notification for draft-leiba-rfc2119-update-00.txt
References: <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Aug 2016 15:35:21 -0000

I don't like this update.

Almost every sentences uses the passive voice. I think the use of "can," "are often," "do not have to be," and so on, is an awkward attempt to work around the use of the keywords as currently defined, or as redefined. These two usages do not help readability and clarity.

How does this update affect interpretation of existing documents?

It's ironic, I think, that the active voice clause, "Authors who follow these guidelines should incorporate this phrase" uses an uncapitalized "should," and I think it should be a "MUST."

To Scott's semi-serious suggestion to deprecate "SHOULD," I'm hesitant. If there were another word for "do this unless you have a really good reason not to," I'd go for it. "Reasons not to" must be documented wherever possible, though sometimes not all reasons can be foreseen (see what I did there?).

To another comment in the thread: I imagine that setting a reader to emphasize all caps would be annoying when reading specs with pronounceable acronyms. 


On 8/9/16, 4:08 PM, "ietf on behalf of Barry Leiba" < on behalf of> wrote:

>This draft should be self-explanatory -- and please be sure to look at
>Section 1.1 for some explanations that may short-cut some of the
>The bottom line is to update BCP 14 (RFC 2119) to
>(1) make it clear that the key words MUST(/NOT), SHOULD(/NOT), and MAY
>are only key words when they're in ALL CAPS, and
>(2) deprecate the use of the variants (SHALL, RECOMMENDED, OPTIONAL)
>so as to avoid reserving an unnecessarily number of key words.
>Discussion here, please, before Ben, who has kindly agreed to
>AD-sponsor this, sends it out for last call.  And we do expect there
>to be some significant discussion on this one.
>On Tue, Aug 9, 2016 at 2:55 PM,  <> wrote:
>> A new version of I-D, draft-leiba-rfc2119-update-00.txt
>> has been successfully submitted by Barry Leiba and posted to the
>> IETF repository.
>> Name:           draft-leiba-rfc2119-update
>> Revision:       00
>> Title:          Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
>> Document date:  2016-08-09
>> Group:          Individual Submission
>> Pages:          4
>> URL:  
>> Status:
>> Htmlized:
>> Abstract:
>>    RFC 2119 specifies common key words that may be used in protocol
>>    specifications.  This document aims to reduce the ambiguity by
>>    clarifying that only UPPERCASE usage of the key words have the
>>    defined special meanings, and by deprecating some versions of the key
>>    words.