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

Alfred Hönes <ah@TR-Sys.de> Fri, 18 May 2012 19:39 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D13021F864E for <urn@ietfa.amsl.com>; Fri, 18 May 2012 12:39:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.26
X-Spam-Level:
X-Spam-Status: No, score=-97.26 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEIgkaKJoVMN for <urn@ietfa.amsl.com>; Fri, 18 May 2012 12:39:23 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 7B09C21F863E for <urn@ietf.org>; Fri, 18 May 2012 12:39:22 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA293629876; Fri, 18 May 2012 21:37:57 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA28021; Fri, 18 May 2012 21:37:55 +0200 (MESZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <201205181937.VAA28021@TR-Sys.de>
To: barryleiba@computer.org
Date: Fri, 18 May 2012 21:37:54 +0200
In-Reply-To: <CAC4RtVDYmVJyPUvy1+V0oaZK+6YoKFbehgSO_h-6-GtEP-1qPg@mail.gmail.com> from Barry Leiba at May "18, " 2012 "12:44:14" pm
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 7bit
Cc: urn@ietf.org
Subject: Re: [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 19:39:24 -0000

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


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

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):

>
>> 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:
>
> 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 ietf@ietf.org:
> https://www.ietf.org/mail-archive/web/ietf/current/msg73338.html

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.


>
> 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