Re: [urn] A 'newbie' question on the terminology used in RFCs

Juha Hakala <> Wed, 25 January 2012 12:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DEDCD21F8629 for <>; Wed, 25 Jan 2012 04:33:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.246
X-Spam-Status: No, score=-5.246 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id deZEPahsrPSt for <>; Wed, 25 Jan 2012 04:33:27 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D303C21F861B for <>; Wed, 25 Jan 2012 04:33:26 -0800 (PST)
Received: from [] ( []) by (8.14.4/8.14.4) with ESMTP id q0PCXMgH006786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Jan 2012 14:33:22 +0200
Message-ID: <>
Date: Wed, 25 Jan 2012 14:33:22 +0200
From: Juha Hakala <>
User-Agent: Thunderbird (Windows/20100228)
MIME-Version: 1.0
To: Alfred Hoenes <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [urn] A 'newbie' question on the terminology used in RFCs
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Jan 2012 12:33:28 -0000


RFC 2119, which is the sole authority as regards this issue, uses 
(certainly intentionally) both upper-case and lower-case versions of 
these words, and these terms do have different semantics:

>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation...

I have followed the policy Alfred outlines below which is identical to 
the spirit of RFC 2119. In the I-Ds I have drafted must and MUST do not 
mean the same thing. IMHO it would be less clear to the reader what the 
relation between MUST and terms like have to, ought to, etc. would be. 
And there would be no place to check this.

My conclusion from the discussion is that there is no need to change the 
current, RFC 2119 -based policy. I fail to see how any changes could 
make semantics more clear but there are definitely many ways to create a 
muddle by using terms which are not within the scope of RFC 2119. And 
IMHO we ought to (;-)) avoid such a situation.

Alas, not all standards organizations follow an identical policy as 
IETF. For instance, if an RFC is published as an ISO standard, some 
subtle changes will be necessary. I have been asked to change a quote 
(!) from an RFC since the terminology in the quote did not match the ISO 


Alfred � wrote:
> [[ speaking as author and document editor ]]
> Julian and Bengt,
> please see my inline comments below.
> On 2012-01-24, Julian Reschke wrote
>> On 2012-01-24 11:43, Bengt Neiss wrote:
>>> Since I am new to IETF standardization and after reading
>>> draft-ietf-urnbis-rfc3188bis-nbn-urn-02.txt there is a question I would
>>> like to ask....
>>> In the text 'SHOULD' and 'should' are used as well as 'MAY' and 'may'.
>>> Is this intentional and are there a difference in understanding
>>> lower-case versus upper-case words (ie. upper-case is interpreted as
>>> stated in RFC 2119 and lower-case is a less strict use of the word) or
>>> should the use of lower-case words (in this case) be considered a 'typo'
>>> that should be corrected to upper-case (and as such be interpreted
>>> according to RFC 2119)?
>> The latter.
> No.  That is deliberate.
> 'should' and 'may' are perfect, plain english words.
> Only the fully capitalized versions carry the RFC 2119 semantics:
> --- start of quotes from RFC 2119 ----
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.
> ...
> 5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
>    truly optional.  One vendor may choose to include the item because a
>    particular marketplace requires it or because the vendor feels that
>    it enhances the product while another vendor may omit the same item.
>    An implementation which does not include a particular option MUST be
>    prepared to interoperate with another implementation which does
>    include the option, though perhaps with reduced functionality. In the
>    same vein an implementation which does include a particular option
>    MUST be prepared to interoperate with another implementation which
>    does not include the option (except, of course, for the feature the
>    option provides.)
> --- end of quotes from RFC 2119 ----
>> It's best to avoid these lowercase variants.
> I do not share this opinion, in general.
> Avoiding the normal forms and semantics of everyday auxiliary verbs
> seems to be some kind of silly self-enforced "political correctness".
> In cases where text talks about very formal procedures however,
> I try to avoid the lowercase forms, just to avoid iterated discussions
> whether the capitalized form should be used, besides in one important
> case of circumstances:
> When the spirit of current normative text (from inside or outside the
> IETF) is referred to (yet not quoted literally, e.g. for reasons of
> potential copyright issues, or to allow future evolution of those
> documents), but the I-D/RFC text does not aim at overriding that
> 'foreign' normative text, I have been advised several times to keep
> the lowercase form.  For instance, when reporting on requirements
> within the rfc3187bis and rfc3188bis drafts that are laid down in
> external standards (ISO 2108 for ISBN, National Library standards
> for NBNs) but carry on to fulfill generic URN requirements for the
> URN:ISBN and URN:NBN documents, the latter use the lowercase forms
> in order to avoid perceived attempts to override the applicable
> normative documents.
>> If you don't want to invoke RFC 2119, use "might", "can", "ought to",
>> "advised"...
> There are lots of differences in the semantics that might [ no pun
> intended :-) ] make these choices less appropriate than "may",
> "should", or "must", in specific cases.
> Kind regards,
>   Alfred.


  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email, tel +358 50 382 7678