[urn] normative language -- a new convention

Alfred Hönes <ah@TR-Sys.de> Fri, 18 May 2012 08:35 UTC

Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 183B421F85EF for <urn@ietfa.amsl.com>; Fri, 18 May 2012 01:35:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.294
X-Spam-Status: No, score=-99.294 tagged_above=-999 required=5 tests=[AWL=1.455, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, GB_I_LETTER=-2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GWiNswWMmSoZ for <urn@ietfa.amsl.com>; Fri, 18 May 2012 01:35:21 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de []) by ietfa.amsl.com (Postfix) with ESMTP id 89DA521F85D7 for <urn@ietf.org>; Fri, 18 May 2012 01:35:20 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: $/16.3.2) id AA287670036; Fri, 18 May 2012 10:33:56 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id KAA24888; Fri, 18 May 2012 10:33:55 +0200 (MESZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah@TR-Sys.de>
Message-Id: <201205180833.KAA24888@TR-Sys.de>
To: urn@ietf.org
Date: Fri, 18 May 2012 10:33:54 +0200 (MESZ)
X-Mailer: ELM [$Revision: $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
Subject: [urn] normative language -- a new convention
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 May 2012 08:35:23 -0000

<speaking both as an individual and as a co-chair>

With URN Namespace registration documents, we have the recurring
issue of choosing the appropriate normative language to indicate
requirements imposed by the document itself and those imposed by
external standards/documents for the underlying namespace, and to
distinguish these from the common form of the plain verbs as used
in natural language.

With the approval of the IESG, RFC 6329 (published in April 2012)
has introduced a new convention (see Section 3 of that RFC), and
I suggest that we liberally adopt this method for our WG documents:

- RFC 2119 terms (in all capital letters) denote normative document
  requirements according to RFC 2119, which MUST be at a protocol
  or meta-protocol level and conformance to these terms needs to be
  verifiable from external behavior of the protocol entities.

- The lowercase forms with initial capital:  "Must", "Must Not",
  "Shall", "Shall Not", "Should", "Should Not", "May", and "Optional"
  are to be interpreted as quotations of external normative
  requirements posed by other SDOs (in particular, ISO, in our
  current cases of bibliographic URN Namespaces).

- The all-lowercase forms still carry their natural language meaning.

  It is regarded good practice by some folks to avoid these lowercase
  forms, but opinions on that advice differ largely.  Note that the
  former RFC Editor, Bob Braden -- who once, as the editor of STD 3
  (RFCs 1122 and 1123) had introduced the systematical use of these
  all-uppercase terms into the Internet Standard document set --,
  once stated that the proportion of non-capitalized to capitalized
  "must"/"should"/"may" is one kind of quality scale for RFCs.

It should be recalled that Section 6 of RFC 2119 literally says about
the capitalized forms:

  "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 or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for

Kind regards,


| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |