[urn] normative language -- a new convention

[Alfred Hönes <[e-mail]>]

<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
   interoperability."


Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+