Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-03

Alfred Hönes <> Fri, 19 October 2012 05:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62CCF21F859C for <>; Thu, 18 Oct 2012 22:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -98.043
X-Spam-Status: No, score=-98.043 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6brH8e7nQsXf for <>; Thu, 18 Oct 2012 22:00:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BA3CC21F859A for <>; Thu, 18 Oct 2012 22:00:23 -0700 (PDT)
Received: from by w. with ESMTP ($Revision: $/16.3.2) id AA098412683; Fri, 19 Oct 2012 06:58:03 +0200
Received: (from ah@localhost) by (8.9.3 (PHNE_25183)/8.7.3) id GAA22622; Fri, 19 Oct 2012 06:57:58 +0200 (MESZ)
From: Alfred Hönes <>
Message-Id: <>
Date: Fri, 19 Oct 2012 06:57:58 +0200
In-Reply-To: <> from "" at Oct "18, " 2012 "09:44:13" pm
X-Mailer: ELM [$Revision: $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 7bit
Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Oct 2012 05:00:26 -0000

URNbis folks,

eventually, the long expected new version of the rfc3406bis draft
is also available from the Internet-Draft archives.

Speaking as the draft editor:

This draft version incorporates the changes proposed on my
"A way forward ..." proposal posted to this list on  5 July and
archived at
taking into account the feedback received for this (in so far as
it related directly to this draft), and it contains many additional
changes based on an evaluation of all on-list and off-list comments
received since the publication of the -02 version.
For a detailed summary of changes, please see below.

Please study this draft in detail and send draft text related
comments.  The plan is to issue one additional draft version next
month before proceeding to WG Last Call for it.

My highest priority for the next days remains bringing out the
pending updates to the namespace-specific WG documents as well;
so please admit that I'll likely still have to defer any followup
discussion until this task is completed.

A few minutes ago, wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Uniform Resource Names, Revised
> Working Group of the IETF.
>       Title           : Defining Uniform Resource Name (URN) Namespaces
>       Author(s)       : Alfred Hoenes
>       Filename        : draft-ietf-urnbis-rfc3406bis-urn-ns-reg-03.txt
>       Pages           : 36

  Note: Please discount for ~13 pg. Boilerplate, References, Change log

>       Date            : 2012-10-18
> Abstract:
>    RFC 2141bis formalizes the concept of Uniform Resource Names (URNs)
>    for persistent, location-independent, resource identifiers within the
>    generic URI system specified in RFC 3986.  To structure and organize
>    URN usage, RFC 2141bis specifies a hierarchy that divides the set of
>    possible URNs into "URN Namespaces" that can be individually defined
>    and managed.  URN Namespaces allow to map existing identifier systems
>    into the URN scheme and thereby make available generic, network-based
>    resolution services for the identified resources (documents,
>    artifacts, and other objects) and metadata related to them.
>    To this end, URN Namespaces need to be defined and specified in a
>    comparable manner, and their Namespace Identifiers (NIDs) need to be
>    registered with IANA, so that naming conflicts are avoided and
>    implementers of services can follow a structured approach in support
>    of various namespaces, guided by the registry to the related
>    documents and the particularities of specific namespaces, as
>    described in these Namespace registration documents.
>    This RFC serves as a design guideline for stakeholders of URN
>    Namespaces and authors of URN Namespace definition and registration
>    documents.  It describes the process to be followed to register a URN
>    Namespace with IANA and the essential content of such documents.
>    This document supersedes and replaces RFC 3406.
> The IETF datatracker status page for this draft is:
> There's also a htmlized version available at:
> A diff from the previous version is available at:
> Internet-Drafts are also available by anonymous FTP at:

This new draft version contains the following incremental change
summary as an Appendix, amended with rationale for some non-changes:

-------- snip --------

C.5.  Changes from URNbis WG I-D -02 to -03

   Due to the scattered discussion of the previous draft version, the
   items below not only list effected changes but also give rationale
   for where suggested changes have not been applied.

   Document title shortened to better reflect entire purpose of

   Abstract: revised and shortened (comments from SM).

   Rephrased 1st para to put emphasis on name binding property (derived
   from list discussion on related topic, Keith Moore et al.).
   Amended / modified text to better reflect the intended audience of
   the memo and its contents, and to accommodate the evolution of the
   rfc2141bis I-D.
   Wordsmithing Assumption: "_well_ recognized" (Lars Svensson).
   Contrary to a proposal (PSA), the draft text keeps the Assumptions
   separate from the consequences/conclusions drawn from these; the
   registration process is what is to be followed to maintain the
   assumption, not the 2nd assumption itself.
   Text reworked based on comments (SM, PSA, et al.).
   The single paragraph with a historical perspective on previous
   documents is deemed rather helpful for the intended audience (note
   the confusing artifact caused by RFC Editor mistake, giving the
   replacement of a BCP a different BCP number!), and it serves to
   capture important motivations for the document revision effort;
   therefore, it is kept in the draft.
   The pargraph describing the purpose of the document has been
   rephrased.  It isn't barely about an IANA procedure, it is also about
   what prospective registrants are well advised to consider before
   deciding on a new Namespace and the processes they have to implement,
   and finally capturing the results in a URN Namespace registration

   Section 2:
   Amended by text describing the 3 methods available to Namespace
   designers / stakeholdes to make component resources of structured
   resources identifiable/accessible.
   Some existing text reworded based on comments (SM et al.).
   It has been argued that text on URN Namespaces in s2 would better be
   placed into the rfc2141bis document, but on the other hand, it has
   been argued that text introducing and discussing Namespace properties
   from rfc2141bis should better be placed into this memo.  To keep both
   documents as much self-contained as practical, text on URN Namespaces
   of specific interest to prospective stakeholders of URN Namespaces
   and authors of registration documents has been kept in s2 of this
   draft, and new such material has been added there.  (The rfc2141bis
   draft now points to this.)

   s3.3: Reworded "benefit" clause to clarify distinction between the
   community interested in a new Namespace and the Internet community at
   large (corollary to comments on and revision of s4.4.2.).

   s4: (dealing with comments from SM, PSA)
   The justification for the need to consider and specify registration
   maintenance procedures has been in RFC 3406; the text from there has
   been updated according to our chartered, to update for RFC 5226.
   This matter needs to be taken into account by prospective Namespace
   owners, and thus the text makes sense in this document.
   Reorganization of subsequent text made it logically necessary to
   include into this section a high level description of the list.  The nominal review period is left a four
   weeks in this draft revision, but a Note has been added to s4
   indicating that this is an upper limit to accommodate headroom,
   whereas the designated expert(s) may always come to a conclusion
   Repeated references to IANA have been consolidated.
   The common shorthand designation "IANA experts" for the designated
   expert(s) supporting IANA in the maintenance of the URN NID registry
   is now being avoided.

   s4.1: No technical changes.  The continued use of the "X-" prefix for
   Experimental Namespaces does not violate RFC 6648 because this is
   legacy practice, experimental NIDs are not being registered, and this
   memo again prohibits the use of Experimental Namespaces in the open

   Text reorganized, incorporating material from s4.4.4 (see below).
   The text on the (modified) "IETF Review" policy has been upgraded
   from RFC 3406 (and thereby effectively shortened).  It serves to give
   concise information to the expected primary audience of the document,
   applicants for Namespaces, which according to experience are rather
   unlikely inclined to read the full RFC 5226, but just need to know
   what is said in the single sentence in the draft.  Further, this
   sentence supplies the background information for the following
   sentences and thus improved the readability of the text.  Therefore,
   no substantive changes applied here.

   s4.4: text amended to avoid confusion about registration template.

   s4.4.1 and s4.4.2: Heavily reworked based on discussion (Leslie, PSA,
   Juha, et al.).  Bullet lists now point to clauses of the registration
   template where working on the text to be supplied there will likely
   give insights to answer the basic questions to be answered here.
   A NOTE now tentatively allows to include a combined Namespace and
   Community Considerations section into a Namespace registration
   document, if the expert review admits it.

   s4.4.3: The first sentence lays the foundation for the subsequent
   sentences and gives the appropriate reference (to BCP 72); hence it
   is regarded as non-disposable -- no change.
   Repeated negative experience has motivated the addition of a hint
   that emphasizes that WG documents including URN Namespace definitions
   need to go through the urn-nid process before they can be forwarded
   to the IESG (document writeup requirement).

   s4, s4.4.4: Last paragraph ostensibly belonging to s4.4.4 moved to
   end of s4, then adjusted to context.  (The RFC format doesn't allow
   to recognize the continuation of a higher-level section after the
   inclusion of sub-sections.)

   s4.3, s4.4.4: The checklist of syntactical constraints for NIDs of
   formal namespaces was intended as a checklist for IANA; following
   comments from Lars Svensson, it has been moved from s4.4.4 to s4.3
   and related text has been modified accordingly.

   s4.4.4: substantially revised (comments from Lars Svensson et al.).

   IANA Cons. (s6): Added request to IANA to clarify the procedures for
   Formal NIDs in the list of ptorocol parameter registries.

   Updated and expanded Acknowledgements.

   References: RFC 3339 demoted to Informational; you don't need to read
   it to insert the date into the registration template, the applicable
   pattern is shown there directly; this change avoids a potential
   normative downref.

   Clarified role of Appendices.

   Appendix A:
   Clarified purpose of the explanations in curly braces embedded in the
   annotated registration template.  Use term "clause" throughout.
   Removed Notes from template that served to explain previous changes.
   Template now provided in both annotated and bare form (suggestion
   from SM); once finalized, both forms will be provided in xml2rfc
   format (location to be decided: IETF Tools and/or IANA).
   Added new items to registration template for Purpose of Namespace
   (short description of named resources), applicability of <query> part
   and supported query instructions (if any), and applicability of
   <fragment> part.

   Appendix B: The document organization is carried over from RFC 3406.
   Modified title of App. B, declared it Informative.

   This Appendix C.5 added; previous Appendix D (Issues) dropped.

   Multiple editorial fixes and enhancements.

-------- snip --------

The summary "Essential Changes since RFC 3406" Appendix will be
filled in during the next update cycle.

Best regards,