RE: SHOULD vs MUST case sensitivity

"Hallam-Baker, Phillip" <> Tue, 01 July 2008 15:12 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 11D583A69B3; Tue, 1 Jul 2008 08:12:54 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A1CC3A689F for <>; Tue, 1 Jul 2008 08:12:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.324
X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=2.878, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IkLRg0ZCXVQ1 for <>; Tue, 1 Jul 2008 08:12:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AADFA3A69B3 for <>; Tue, 1 Jul 2008 08:12:50 -0700 (PDT)
Received: from ( []) by (8.12.11/8.13.4) with ESMTP id m61FD0eG011914; Tue, 1 Jul 2008 08:13:00 -0700
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Jul 2008 08:13:00 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: SHOULD vs MUST case sensitivity
Date: Tue, 1 Jul 2008 08:12:59 -0700
Message-ID: <>
Thread-Topic: SHOULD vs MUST case sensitivity
Thread-Index: Acjau06h18oK0HPQTSWvw8N/06V9RAA0CiQ+
References: <><><><><><g3ror8$2b9$><><><2D990430F5F5D3C7984BDFDF@p3.JCK.COM><> <><><><><><00cd01c8da42$592bd280$6801a8c0@oemcomputer><><000801c8da4a$d747c860$6801a8c0@oemcomputer><><><025d01c8daba$e15b7a20$> <5CF12EE3-CA54-4493-B286-2FB3EC812337@cisco! .com>
From: "Hallam-Baker, Phillip" <>
To: "Ralph Droms" <>, "Spencer Dawkins" <>
X-OriginalArrivalTime: 01 Jul 2008 15:13:00.0330 (UTC) FILETIME=[F34440A0:01C8DB8C]
Cc: Randy Presuhn <>, IETF Discussion <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============0899254980=="

Looks good, but needs some smitthing.
I think that the sense that I would want is:
* Whenever the keywords are used they are to be considered normative
* Whenever the keywords are used they SHOULD be capitalized
* Editors SHOULD avoid use of normative keywords for non-normative language, even in drafts.
The reason for the last is that it is very common for folk to go through a doucument 'to make sure all the keywords are capitalized as they should be'. This is particularly so where older RFCs are being revised. A standards document should be robust in the face of search and replace changes to the text.
I would ideally like to see a normative keyword tag added to the XML2RFC markup to make it easy to construct tables of normative requirements as are required for interop testing and are beginning to appear in some specs.
So the marku would be something like:
<t>Normative keywords <normative key="should">Only use normative keywords to specify normative language</normative> only be used to specify normative language.</t>
And this would allow a table such as the following to be created:
Section 2.1 p 3: Only use normative keywords to specify normative language


From: on behalf of Ralph Droms
Sent: Mon 6/30/2008 10:11 AM
To: Spencer Dawkins
Cc: Randy Presuhn; IETF Discussion
Subject: Re: SHOULD vs MUST case sensitivity

Would a reasonable BCP for future docs looks something like:

   terms defined in RFC 2119 are to be capitalized for clarity; 
alternatives for RFC 2119 terms, such as "ought" and "can" are to be 
used in
   non-normative text to avoid confusion

- Ralph

On Jun 30, 2008, at Jun 30, 2008,10:08 AM, Spencer Dawkins wrote:

> Without reference to other points that have been made in this 
> thread, it's also worth noting that Gen-ART reviewers have been 
> challenging 2119-ish statements in drafts under review for several 
> years, assuming that capitalization is significant, and discouraging 
> upper-casing for emphasis.
> It would be lovely to have the current practice written down 
> clearly, so authors and editors aren't surprised when this happens 
> (and we never have to revisit the topic).
> Thanks,
> Spencer
>> However, there is abundant evidence to support argument
>> that prospective RFC authors should use the ALL-CAPS version of
>> these words - if for no other reason than because it removes any
>> possibility of doubt.  The evidence to support this is based at
>> least partly on current usage - such as a BCP like RFC 2119 is
>> meant to reflect.  It is also based at least in part on the the
>> arguments put forward in this thread.  And finally, it is based
>> at least in part on the common-sense proposition that anything
>> that adds clarity to a specification is generally a good thing.
>> Hence I believe the one thing we should take away from
>> this discussion is that - while use of the ALL-CAPS version of
>> the requriements level terminology in RFC 2119 is probably not
>> technically required to indicate the intended usage - it is a
>> very good idea to do this.  Further, if we assume that is the
>> case (and I think reasonable people will agree that it is),
>> then continuing the argument about the semantics in this case
>> is merely a distraction from useful discussion and clarity in
>> the work we all want to be doing.
>> --
>> Eric Gray
>> Principal Engineer
>> Ericsson
>>> -----Original Message-----
>>> From: [] On
>>> Behalf Of Dave Crocker
>>> Sent: Sunday, June 29, 2008 10:32 PM
>>> To: Randy Presuhn
>>> Cc: IETF Discussion
>>> Subject: Re: SHOULD vs MUST case sensitivity
>>> Randy Presuhn wrote:
>>> >> English is not case sensitive.
>>> >
>>> > Not so.  Case has long been used for emphasis in environments
>>> > lacking other typographical means, such as bolding, underlining,
>>> > or italicization.
>>> Emphasis is not semantics.
>>> Normative intent is semantic.
>>> d/
>>> --
>>>   Dave Crocker
>>>   Brandenburg InternetWorking
>>> _______________________________________________
>>> Ietf mailing list
>> _______________________________________________
>> Ietf mailing list
> _______________________________________________
> Ietf mailing list

Ietf mailing list

Ietf mailing list