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

Ted Hardie <ted.ietf@gmail.com> Fri, 18 May 2012 15:33 UTC

Return-Path: <ted.ietf@gmail.com>
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 563A821F8564 for <urn@ietfa.amsl.com>; Fri, 18 May 2012 08:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.444
X-Spam-Level:
X-Spam-Status: No, score=-4.444 tagged_above=-999 required=5 tests=[AWL=0.855, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 BBki5I-ePCmt for <urn@ietfa.amsl.com>; Fri, 18 May 2012 08:33:35 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAE621F8562 for <urn@ietf.org>; Fri, 18 May 2012 08:33:35 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so3157354vbb.31 for <urn@ietf.org>; Fri, 18 May 2012 08:33:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=9kUHFbpQ2LW9yc6ylyjBqLSwFN/M5IkkRFkpsX+SeOo=; b=AAlrhPn8WhOQ9TkogkOXQbr0fy3obgwm1AFGpEz1fP/XiqEA/I1lcn60b0ePTWdiqF hQYQFcbcE+BQ2f6ss/o/lnnZjOTLMNjORmgmq9C+BFZEpSSrYj7ftzERg5msfxAQeCID v7i8ezLUmXIUDTbTU5yqTPBmqFHM7tEu7wZfqUpwxKmuQ48tCoGMSzxB38mF1iA6GwE1 sXLRlKV/+Tfs37i9JmXVwQ5b9o9rHrDYF47M4bLkh2UGSj9EOUYrwQzcExpADa0gC+Kl GQBGRXrq1xNdXtlsFkU5dbrOwW9QKyYvCZKaYqlOGDh0U19KqbY2LA0zJkL7GCMntj12 zaWw==
MIME-Version: 1.0
Received: by 10.52.73.42 with SMTP id i10mr5586660vdv.116.1337355214776; Fri, 18 May 2012 08:33:34 -0700 (PDT)
Received: by 10.52.162.99 with HTTP; Fri, 18 May 2012 08:33:34 -0700 (PDT)
In-Reply-To: <201205180833.KAA24888@TR-Sys.de>
References: <201205180833.KAA24888@TR-Sys.de>
Date: Fri, 18 May 2012 08:33:34 -0700
Message-ID: <CA+9kkMCwOKo=gJqz3mfLRcG2i_NkAm+QNzU1VTcCnU8G0N2HuQ@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: =?ISO-8859-1?Q?Alfred_H=CEnes?= <ah@tr-sys.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 15:33:36 -0000

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 <ah@tr-sys.de> wrote:
> <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:  ah@TR-Sys.de                     |
> +------------------------+--------------------------------------------+
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn