RE: [rtcweb] Uppercase question for RFC2119 words

"Drage, Keith (Nokia - GB)" <> Wed, 30 March 2016 19:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60B8812D8DC; Wed, 30 Mar 2016 12:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gT84TBMngq_O; Wed, 30 Mar 2016 12:28:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 89AAF12D8C0; Wed, 30 Mar 2016 12:28:46 -0700 (PDT)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id AE6A5E41A2EDA; Wed, 30 Mar 2016 19:28:40 +0000 (GMT)
Received: from ( []) by (GMO-o) with ESMTP id u2UJSeHg022418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Mar 2016 19:28:40 GMT
Received: from ( []) by (GMO) with ESMTP id u2UJSdXj025878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Mar 2016 21:28:39 +0200
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 30 Mar 2016 21:28:39 +0200
From: "Drage, Keith (Nokia - GB)" <>
To: EXT Dave Cridland <>, Barry Leiba <>
Subject: RE: [rtcweb] Uppercase question for RFC2119 words
Thread-Topic: [rtcweb] Uppercase question for RFC2119 words
Thread-Index: AQHRirpc9Kg4wBKJA0+WsIoM8QGwTg==
Date: Wed, 30 Mar 2016 19:28:39 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <20160328104731.GO88304@verdi> <> <20160328132859.GP88304@verdi> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADEB685FFR712WXCHMBA11z_"
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Approved-At: Thu, 31 Mar 2016 10:47:57 -0700
Cc: IETF discussion list <>, "Heather Flanagan (RFC Series Editor)" <>, "" <>, Dave Crocker <>, IESG <>
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, 30 Mar 2016 19:28:49 -0000

This discussion seems to have started because rtcweb produced a document where the status (BCP, informative or standards track) was not clear and I could not even work it out from the use of pseudo normative language.

I would note that the meaning of even lower case “must” has to be clear, and in my view there is frequently an important distinction between “is obliged to” and “is expected to”, and even “should do”, all of which appear to be allowed by the Webster definition. Further, in the Oxford definition, only the first of these seems to be meant, so there is potentially an Atlantic divide here.

Further, when I have questioned in the past what some author has meant by using “must”, we frequently end up understanding that it was not meant at all. Sometimes it is hiding a somewhat differently phrased “MUST” requirement.

I could make similar arguments for other modal auxiliarys.

My other arguments for avoiding lower case versions are that other standards organizations (with one exception) do use lower case versions to explicitly define requirements, and the distinction of a usage within IETF is not necessarily understood, and secondly that it is far too easy for an editor with the misapplication of a single keypress to convert the case of a word.



From: rtcweb [] On Behalf Of EXT Dave Cridland
Sent: 30 March 2016 20:01
To: Barry Leiba
Cc: IETF discussion list; Heather Flanagan (RFC Series Editor);; IESG; Scott O. Bradner; Dave Crocker
Subject: Re: [rtcweb] Uppercase question for RFC2119 words

On 30 March 2016 at 18:59, Barry Leiba <<>> wrote:
>> That such a rule differs from natural English -- which does not typically
>> alter semantics based on case -- and that most readers of RFCs will not have
>> such detailed knowledge of RFC2119 nor read RFCs with the care such a rule
>> demands, my question BARRY and adam and EveryOne Else, is what makes anyone
>> think that such a rule must (MUST?) ensure proper reading of RFCs so as to
>> distinguish between normative portions and advisory portions?
> Sorry, I think that's nonsense. RFC 2119 and its capitalized keywords are
> well known to anyone reading any specifications, these days. I think we can
> actually assume a priori knowledge of RFC 2119, for the most part. What I
> think would be far more surprising is this notion that the keywords, noted
> and referenced in capitals, also have the same precise meaning and force
> when written normally.

I agree with the first and third sentences of what Dave Cridland said,
but I think we have to be a little careful about the second.  What I
think we can assume is an a priori knowledge of some of what 2119
says: that there are these capitalized key words that have special
meanings.  But it's quite clear from reviewing a lot of documents (one
of the fun things one gets to do as AD) that many writers do not know
how 2119 actually defines those.  I see significant misunderstandings
about "SHOULD" and "MAY" all the time, examples of which I can give
you if you like.  And one of my favourites is when someone used
"RECOMMENDED", I questioned it in a comment, and the response was,
"Yes, maybe we should switch that to 'SHOULD'."

For future reference, I tend not to zero-index my sentences. ;-)

I think that MUST/SHOULD/MAY (the former two tempered by NOT) are well-understood, although the strength of SHOULD is usually underestimated. OPTIONAL is probably obvious enough (though its implications may not be), and SHALL/RECOMMENDED are uncommon enough that they're probably not understood nearly as well.

As a complete side thing, I wonder how this all seems to
German-speakers, as German uses initial caps for all nouns.  I wonder
if anyone even notices if someone fails to do that.  I wonder if it
becomes puzzling, perhaps in some instances.