Subject: [urn] normative language -- a new convention

From: Alfred Hönes <[email-masked]>
Date: Fri, 18 May 2012 10:33:54 +0200 (MESZ)

<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: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Ted Hardie <[email-masked]>
Date: Fri, 18 May 2012 08:33:34 -0700

Howdy,

I am quite concerned about the convention proposed.  Using case to
distinguish the origin of a requirement seems to me a very fragile
method compared to simply quoting the appropriate standard in its
existing language.  Consider, for example, the use of a screen reader
by a developer; I am not confident that it would preserve this signal.

regards,

Ted Hardie

On Fri, May 18, 2012 at 1:33 AM, Alfred HÎnes <[email-masked]> wrote:
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: Barry Leiba <[email-masked]>
Date: Fri, 18 May 2012 12:44:14 -0400

Alfred,

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

As the responsible AD, I am at a loss to understand how it's at all
appropriate for you to make this suggestion as chair.  Please explain
specifically where the authority to do that comes from.

> I suggest that we liberally adopt this method for our WG documents:

As a participant, I suggest that this is a very bad idea.  Using ALL
CAPS vs lower case is controversial enough -- see the thread I started
the other day on [email-masked]:
https://www.ietf.org/mail-archive/web/ietf/current/msg73338.html

And note that Marshall Eubanks referred this thread to that one this morning.

Given that there's already no consensus on using "MUST" and "SHOULD"
vs "must" and "should", I would be very hesitant to advocate the
widespread addition of "Must" and "Should" with yet different nuances.
 I urge you not to go there.

In any case, I urge anyone who cares about this issue to pursue it on
the IETF discussion list, in the thread I linked to above, and not to
discuss it here.

Barry, Applications Area Director

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 18 May 2012 21:37:54 +0200 (MESZ)

Barry,

let me quickly respond to the main part of your comments and
follow up later to other aspects, after catching up with the
discussion you are pointing to...

> appropriate for you to make this suggestion as chair.  Please
> explain specifically where the authority to do that comes from.

Some time ago, we had some discussion on the underlying topic on the
urn list, and it is one of the tasks of a co-chair to point out ways
forward in case of controversies; for instance, Section 6.1 "WG Chair"
of RFC 2418 says:

|  The Working Group Chair is concerned with making forward progress
|  through a fair and open process, and has wide discretion in the
|  conduct of WG business.  [...]

So observing a Standards Track RFC published less than 4 weeks ago
with an apparently Solomonian method to deal with the topic, which
obviously has been accepted by the (previous) IESG, I think that was
reason and justification enough to *suggest* this method to the WG
as well, assuming consistent, continued support for it in the IESG.
You also might have observed that in my original posting,
I deliberately obstained from stating a personal preference;
I even mentioned diverging opinions.

Please note that this was not a *decision*, but a *suggestion* for
a way forward (and awaiting feedback from the list):

> As a participant, I suggest that this is a very bad idea.

Obviously, opinions vary; at least, the text of RFC 6329 once has
found IETF (and IESG) consensus.

> Using ALL CAPS vs lower case is controversial enough  ...

It shouldn't be controversial, given that even RFC 2119 deliberately
uses "MUST" and "must" (e.g., in the quote I included in my original
posting), and the 'grandfather' of the RFC 2119 style keywords, STD 3,
contains, for example, an almost threefold number of instances of
"may" over instances of "MAY".

> -- see the thread I started the other day on [email-masked]:

It once has been explained to me that the phrase "often capitalized"
in RFC 2119 refers to the practice in published RFCs, as observed
during the development of RFC 2119.

I *personally* always understood RFC 2119 in the way you state it:

| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
| document are to be interpreted as described in [RFC2119] when they
| appear in ALL CAPS.  These words may also appear in this document in
| lower case as plain English words, absent their normative meanings.

I'll happily adopt this boilerplate text now that I know it will be
acceptable.

Kind regards,
  Alfred.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 18 May 2012 16:01:27 -0400

>> explain specifically where the authority to do that comes from.
...
> I even mentioned diverging opinions.

OK.  The reason that caught my attention is that many IETF
participants aren't sure of the role of the chair, and the limitations
of chairs' (and ADs') control.  When one explicitly says that one is
speaking as a chair, one should have a good reason to (declaring
consensus, moderating discussion, doing process management, and so
on).  There's no reason to speak ex-cathedra when one's just informing
the working group of something that might interest them, and I think
chairs should be careful to avoid confusing things by saying they're
acting as chair when they don't need to.

> a way forward (and awaiting feedback from the list):

Exactly the reason that "as a participant" is enough.

> found IETF (and IESG) consensus.
...etc..

As I said, I won't be discussing that part further on this list.  The
discussion continues on the IETF discussion list.

Barry