Skip to main content

Uniform Resource Name (URN) Namespace Definition Mechanisms
draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Author Alfred Hoenes
Last updated 2011-10-31 (Latest revision 2010-12-16)
Replaced by draft-ietf-urnbis-rfc2141bis-urn, RFC 8141
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01
IETF URNbis WG                                                 A. Hoenes
Internet-Draft                                                    TR-Sys
Obsoletes: 3406 (if approved)                           October 31, 2011
Intended status: BCP
Expires: May 3, 2012

      Uniform Resource Name (URN) Namespace Definition Mechanisms
              draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01

Abstract

   Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers.  To structure and
   organize their usage, the URN syntax specifies a hierarchy that
   divides the set of possible URNs into "URN Namespaces" that can be
   individually defined and managed.  URN Namespaces in particular serve
   to map existing identifier systems into the URN system and thereby
   make available generic, network-based resolution services for the
   identified documents, artifacts, and other objects (and their
   metadata).

   To actually leverage such synergetic advantage, URN Namespaces need
   to be 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 document serves as a guideline for authors of URN Namespace
   definition and registration documents.  It describes the essential
   content of such documents and how they shall be structured to allow
   readers familar with the scheme to quickly assess the properties of a
   specific URN Namespace.  Further, this RFC describes the process to
   be followed to get a URN Namespace registered with IANA.

   This document is a companion document to the revised URN Syntax
   specification, RFC 2141bis; it supersedes and replaces RFC 3406.

Discussion

   Discussion of this memo utilizes the urn@ietf.org mailing list.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Hoenes                     Expires May 3, 2012                  [Page 1]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 3, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Hoenes                     Expires May 3, 2012                  [Page 2]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirement Language . . . . . . . . . . . . . . . . . . .  5
   2.  What is a URN Namespace? . . . . . . . . . . . . . . . . . . .  5
   3.  URN Namespace (Registration) Types . . . . . . . . . . . . . .  6
     3.1.  Experimental Namespaces  . . . . . . . . . . . . . . . . .  6
     3.2.  Informal Namespaces  . . . . . . . . . . . . . . . . . . .  6
     3.3.  Formal Namespaces  . . . . . . . . . . . . . . . . . . . .  7
   4.  URN Namespace Registry: Processes for Registration and
       Update . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Experimental Namespaces: No Registration . . . . . . . . .  9
     4.2.  Informal Namespaces  . . . . . . . . . . . . . . . . . . .  9
     4.3.  Formal Namespaces  . . . . . . . . . . . . . . . . . . . . 10
     4.4.  Registration Documents . . . . . . . . . . . . . . . . . . 11
       4.4.1.  Namespace Considerations in Registration Documents . . 11
       4.4.2.  Community Considerations in Registration Documents . . 12
       4.4.3.  Security Considerations in Registration Documents  . . 12
       4.4.4.  IANA Considerations in Registration Documents  . . . . 13
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  URN Namespace Definition Template . . . . . . . . . . 16
   Appendix B.  Illustration  . . . . . . . . . . . . . . . . . . . . 22
     B.1.  Example Template . . . . . . . . . . . . . . . . . . . . . 22
     B.2.  Registration steps in practice . . . . . . . . . . . . . . 24
   Appendix C.  Changes from RFC 3406 . . . . . . . . . . . . . . . . 25
     C.1.  Essential Changes since RFC 3406 . . . . . . . . . . . . . 25
     C.2.  Changes from RFC 3406 to URNbis WG Draft -00 . . . . . . . 25
   Appendix D.  Open Issues . . . . . . . . . . . . . . . . . . . . . 28

Hoenes                     Expires May 3, 2012                  [Page 3]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

1.  Introduction

   Uniform Resource Names (URNs) are resource identifiers with the
   specific requirements for enabling location-independent
   identification of a resource, as well as longevity of reference.
   URNs are part of the larger Uniform Resource Identifier (URI) family
   (see the joint W3C/IETF memorandum, RFC 3305 [RFC3305], and the IETF
   STD 66, RFC 3986 [RFC3986]) with the specific goal of providing
   persistent naming of resources.

   There are two assumptions that are key to this document:

   Assumption #1:  Assignment of a URN is a managed process.

      I.e., not all strings that conform to URN syntax are necessarily
      valid URNs.  A URN is assigned according to the rules of a
      particular namespace (in terms of syntax, semantics, and process).

   Assumption #2:  The space of URN Namespaces is managed.

      I.e., not all syntactically correct URN Namespaces (per the URN
      syntax definition) are valid URN Namespaces.  A URN Namespace must
      have a recognized definition in order to be valid.

   The purpose of this document is to outline a mechanism and provide a
   template for explicit namespace definition, as well as provide the
   mechanism for associating an identifier (called a "Namespace ID", or
   NID), which is registered with the Internet Assigned Numbers
   Authority (IANA) [IANA] in the URN Namespaces registry maintained at
   [IANA-URN].

   The URN Namespace definition and registration mechanisms originally
   have been specified in RFC 2611 [RFC2611], which has been obsoleted
   by BCP 66, RFC 3406 [RFC3406].  Guidelines for documents prescribing
   IANA procedures have been revised as well over the years, and at the
   time of this writing, BCP 26, RFC 5226 [RFC5226] is the normative
   document.  This document is a revision of RFC 3406 based on the
   revised URN Syntax specification RFC 2141bis
   [I-D.ietf-urnbis-rfc2141bis-urn] and RFC 5226.

   The reader is referred to Section 1.1 of RFC 2141bis
   [I-D.ietf-urnbis-rfc2141bis-urn] for a more detailed synopsis of the
   history of documents fundamental for URNs.

   Note that this document restricts itself to the description of
   processes for the creation of URN Namespaces.  If generic
   "resolution" of any so-created URN identifiers is desired, a separate
   process of registration in a global NID directory, such as that

Hoenes                     Expires May 3, 2012                  [Page 4]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

   provided by the DDDS system [RFC3401], is necessary.  See [RFC3405]
   for information on obtaining registration in the DDDS global NID
   directory.

1.1.  Requirement Language

   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 RFC 2119 [RFC2119].
   In this document, these key words describe requirements for the
   process to be followed and the content to be provided in namespace
   definition documents and registration templates.

   For the purpose of this document, its subject is spelled "URN
   Namespace" (in headline case), whereas in other context, "namespace"
   is spelled in lowercase, e.g. to designate a (standard or non-
   standard) identifier system on which a URN Namespace is based.

2.  What is a URN Namespace?

   For the purposes of URNs, a "namespace" is a collection of uniquely-
   assigned identifiers.  That is, the identifiers are not ever assigned
   to more than 1 resource, nor are they ever re-assigned to a different
   resource.  A single resource, however, may have more than one URN
   assigned to it for different purposes.  Such namespace might be
   defined by some pre-established (standard or non-standard) identifier
   system that can be made "network-actionable" by embedding it into the
   URN framework using a specific URN Namespace.  A URN Namespace itself
   has an identifier in order to:

   -  ensure global uniqueness of URNs,

   -  (where desired) provide a cue for the structure of the identifier.

   For example, many identifier systems use strings of numbers as
   identifiers (e.g., ISBN, ISSN, phone numbers).  It is conceivable
   that there might be some numbers that are valid identifiers in two
   different established identifier systems.  Using different
   designators for the two collections ensures that no two URNs will be
   the same for different resources (since each collection is required
   to uniquely assign each identifier).

   The development of an identifier structure, and thereby a collection
   of identifiers, is a process that is inherently dependent on the
   requirements of the community defining the identifier, how they will
   be assigned, and the uses to which they will be put.  All of these
   issues are specific to the individual community seeking to define a
   namespace (e.g., publishing community, association of booksellers,

Hoenes                     Expires May 3, 2012                  [Page 5]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

   protocol developers, etc.); they are beyond the scope of the IETF URN
   work.

   This document outlines the processes by which a collection of
   identifiers satisfying certain constraints (uniqueness of assignment,
   etc.) can become a bona fide URN Namespace by obtaining a NID.  In a
   nutshell, a template for the definition of the namespace is completed
   for deposit with IANA, and a NID is assigned.  The details of the
   process and possibilities for NID strings are outlined below.

3.  URN Namespace (Registration) Types

   There are three categories of URN Namespaces defined here,
   distinguished by expected level of service and required procedures
   for registration.  Registration processes for each of these namespace
   types are given in Section 4.

3.1.  Experimental Namespaces

   These are not explicitly registered with IANA.

   No provision is made for avoiding collision of experimental NIDs;
   they are intended for use within internal or limited experimental
   contexts.  However, as described below in Section 4.1, these are
   designated by a specific form of the NID to allow differentiation
   (without preexisting knowledge of details) from the other URN
   Namespace types.

   [[ Editorial Note:
   Has anybody ever seen usage of such experimental URN Namespaces?
   According to the observations of the author, three years of RFC 2611
   and nine years of RFC 3406 have constantly seen "tentative grabbing"
   and subsequent usage of NIDs that the stakeholders later have tried
   to register with IANA as Formal NIDs (with varying success).
   So should this kind of namespaces better be dropped and a kind of
   provisional NIDs be created? -- This would be in the spirit of BCP
   100, RFC 4020 [RFC4020], and it would resemble the manner how URI
   Scheme registrations are dealt with (RFC 4395 [RFC4395], [IANA-URI]).
   ]]

3.2.  Informal Namespaces

   These are fully fledged URN Namespaces, with all the rights and
   requirements associated thereto.  Informal namespaces can be
   registered in global registration services.  They are required to
   uphold the general principles of a well-managed URN Namespace --
   providing persistent identification of resources and unique
   assignment of identifier strings.  Informal and formal namespaces

Hoenes                     Expires May 3, 2012                  [Page 6]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

   (described below) differ in the NID assignment.  IANA will assign an
   alphanumeric NID (following a defined pattern) to registered informal
   namespaces, per the process outlined in Section 4.

3.3.  Formal Namespaces

   A formal namespace may be requested, and IETF review sought, in cases
   where the publication of the NID proposal and the underlying
   namespace will provide benefit to some subset of users on the
   Internet.  That is, a formal NID proposal, if accepted, must be
   functional on and with the global Internet, not limited to users in
   communities or networks not connected to the Internet.  For example,
   assume a NID is requested that is meant for naming of physics
   research.  If that NID request required that the user use a
   proprietary network or service that was not at all open to the
   general Internet user, then it would make a poor request for a formal
   NID.  The intent is that, while the community of those who may
   actively use the names assigned within that NID may be small (but no
   less important), the potential use of names within that NID is open
   to any user on the Internet.

   It is expected that Formal NIDs may be applied to namespaces where
   some aspects are not fully open.  For example, a namespace may make
   use of a fee-based, privately managed, or proprietary registry for
   assignment of URNs in the namespace, but it may still provide benefit
   to some Internet users if the services associated have openly-
   published access protocols.

   In addition to the basic registration information defined in the
   registration template (in Appendix A), a formal namespace request
   must be accompanied by documented considerations of the need for a
   new namespace and of the community benefit from formally establishing
   the proposed URN Namespace.

   Additionally, since the goal of URNs is to provide persistent
   identification, some consideration as to the longevity and
   maintainability of the namespace must be given.  The collective
   experience of the IETF community contains a wealth of information on
   technical factors that will prevent longevity of identification.
   Thus, the IESG may elect not to accept a proposed namespace
   registration if the IETF community consensus is that the registration
   document contains technical flaws that will prevent (or seriously
   impair the possibility of) persistent identification, and that it
   therefore should not be published as an RFC.

   In addition to the technical aspects of the namespace and its
   resolution, consideration should be given to the following
   organizatorial aspects:

Hoenes                     Expires May 3, 2012                  [Page 7]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

   -  the organization maintaining the URN Namespace should demonstrate
      stability and the ability to maintain the URN namespace for a long
      time, and/or it should be clear how the namespace can continue to
      be usable/useful if the organization ceases to be able to foster
      it;

   -  it should demonstrate ability and competency in name assignment;
      this should improve the likelihood of persistence (e.g., to
      minimize the likelihood of conflicts);

   -  it needs to commit to not re-assigning existing names and allowing
      old names to continue to be valid, even if the owners or assignees
      of those names are no longer members or customers of that
      organization; this does not mean that there must be resolution of
      such names, but that they must not resolve the name to false or
      stale information, and that they must not be reassigned.

   These aspects, though hard to quantify objectively, should be
   considered by organizations/people considering the development of a
   Formal URN Namespace, and they will be kept in mind when evaluating
   the technical merits of any proposed Formal URN Namespace.  The kind
   of mandate upon which the organization aims to undertake this
   activity might give a strong indication for this evaluation, because
   it likely mirrors the trust that other parties (e.g. states,
   international treaty organizations, professionals' associations,
   etc.) put on the organization.

4.  URN Namespace Registry: Processes for Registration and Update

   Different levels of disclosure are expected/defined for namespaces.
   According to the level of open-forum discussion surrounding the
   disclosure, a URN Namespace may be assigned an identifier or may
   request a particular identifier.

   The IANA Considerations Guidelines document (BCP 26, RFC 5226
   [RFC5226]) suggests the need to specify update mechanisms for
   registrations -- who is given the authority to do so, from time to
   time, and what are the processes.  Since URNs are meant to be
   persistently useful, few (if any) changes should be made to the
   structural interpretation of URN strings (e.g., adding or removing
   rules for lexical equivalence that might affect the interpretation of
   URN IDs already assigned).  However, it may be important to introduce
   clarifications, expand the list of authorized URN assigners, etc.,
   over the natural course of a namespace's lifetime.  Specific
   processes are outlined below.

   The official list of registered URN Namespaces is currently
   maintained by IANA at
   <http://www.iana.org/assignments/urn-namespaces/>.

Hoenes                     Expires May 3, 2012                  [Page 8]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

   The registraty is subdivided into two sub-registries, one for "Formal
   URN Namespaces" and one for "Informal URN Namespaces", and each entry
   there links to a stable repository of the registration document or
   (an escrow copy of) the filled-out registration template.

   The registration and maintenance procedures vary slightly between the
   namespace types.

4.1.  Experimental Namespaces: No Registration

   The NIDs of Experimental Namespaces (Section 3.1) are not explicitly
   registered with IANA.  They take the form:

      X-<nid>

   where <nid> is a string consisting solely of letters, decimal digits,
   and hyphen ("-") characters, as specified by the NID syntax
   specification in Section 2.1 of RFC 2141bis
   [I-D.ietf-urnbis-rfc2141bis-urn].

   No provision is made for avoiding collision of experimental NIDs;
   they are intended for use within internal or limited experimental
   contexts exclusively.

   As there is no registration, no registration/maintenance procedures
   are needed.

   Usage of Experimental URN Namespaces MUST be short-lived and whithin
   a private scope; it MUST NOT be disclosed to the Internet at large,
   e.g. by distribution of software versions that make use of such.

4.2.  Informal Namespaces

   The NIDs of Informal Namespaces are synthesized by the IANA using an
   assigned sequence number and registered in their own sub-registry, as
   indicated in Section 4; they take the format:

      urn-<number>

   where <number> is the decimal representation of a natural number,
   with no leading zeroes.  This sequence number is assigned by the IANA
   on a First-Come-First-Served [RFC5226] basis to registration requests
   for informal namespaces.

   Registrants should send a copy of the registration template (as shown
   in Appendix A), duly completed, to the urn-nid@ietf.org mailing list
   for review and allow for a two-week discussion period for clarifying
   the expression of the registration information and suggestions for

Hoenes                     Expires May 3, 2012                  [Page 9]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

   technical improvements to the namespace proposal.
   [[ NOTE: Longer time is needed in practice!  Increase to 4 weeks? ]]

   After suggestions for clarification of the registration information
   have been incorporated, the template may be submitted for assignment
   of a NID by email to iana@iana.org .

   Registrations may be updated later by the original registrant, or by
   an entity designated by the registrant, by updating the registration
   template, submitting it to the discussion list for a further two-week
   discussion period, and finally resubmitting it to IANA in a message
   to iana@iana.org .

4.3.  Formal Namespaces

   Formal NIDs are assigned via IETF Review, as defined in BCP 26
   [RFC5226].  The designated expert(s) for URN Namespace registrations
   are nominated by the IESG, and their role adheres to the regulations
   in BCP 26, unless specified otherwise below.

   NIDs for Formal URN Namespaces MUST NOT have the forms indicated in
   the preceding two sections for the other two Namespace types.  (The
   detailed formal rules are given below in Section 4.4.4.)  Applicants,
   in concert with the IANA experts, should ensure that the sought NID
   strings are "proper" for the designated purpose, according to common
   sense (and applicable legal rules).

   This means that the Formal NID application is made via submission to
   the IETF of an Internet-Draft that contains the namespace definition
   and targets publication as an RFC of Informational or Standards Track
   category, which needs to be approved by the IESG after performing an
   IETF Last Call on the document and evaluating review comments.  The
   applicant can be an individual or an IETF working group, in alignment
   with the designation of the Internet-Draft.  It is RECOMMENDED that
   the registration documents for NIDs belonging to an established
   standard namespace aim at Standards Track, whereas other applications
   aim at Informational.

   Before publication can be requested, however, the draft namespace
   specification document must undergo an Expert Review process
   [RFC5226] pursuant to the guidelines written here (as well as
   standard RFC publication guidelines).  The template defined in
   Appendix A SHOULD be included as part of an RFC-to-be defining some
   other aspect(s) of the namespace, or it may be put forward as a
   namespace definition document in its own right.  The proposed
   template (including a pointer to a readily available copy of the
   registration document) should be sent to the urn-nid@ietf.org mailing
   list for review.  This list is monitored by the designated expert(s).

Hoenes                     Expires May 3, 2012                 [Page 10]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

   The applicant has to allow for a two-week [[ four-week ? ]]
   discussion period for clarifying the expression of the registration
   information, and SHOULD improve the namespace document and/or
   registration template based on the comments received, under the
   guidance of the designated expert(s), before the IESG reviews the
   document.

   Working groups generally SHOULD seek early expert review for a
   namespace definition document, before they hand it over to the IESG,
   and individual applicants are also advised to seek expert comments
   early enough.  The aforementioned list can be contacted for informal
   advice at any stage.

4.4.  Registration Documents

   The following subsections describe essential, MANDATORY parts of URN
   Namespace registration documents, which will be focal in the expert
   Review process and IETF Review.

4.4.1.  Namespace Considerations in Registration Documents

   The namespace definition document MUST include a "Namespace
   Considerations" section that outlines the perceived need for a new
   namespace (i.e., where existing namespaces fall short of the
   proposer's requirements).

   Considerations MUST include, directly or with the help of referenced
   stable (and preferably readily available) documents:

      -  URN assignment procedures;

      -  URN resolution/delegation;

      -  type of resources to be identified;

      -  type of services to be supported.

   NOTE: It is expected that more than one namespace may serve the same
   "functional" purpose; the intent of the "Namespace Considerations"
   section is to provide a record of the proposer's "due diligence" in
   exploring existing possibilities, for the IESG's consideration.

   [[ Editorial Note: See the endnote of the next section!
   In particular, the above list (from RFC 3406) seems to be rather
   orthogonal to the primary purpose of such section (as indicated in
   the first paragraph), namely to provide evidence for the perceived
   need for the new namespace.
   ]]

Hoenes                     Expires May 3, 2012                 [Page 11]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

4.4.2.  Community Considerations in Registration Documents

   The namespace definition document MUST also include a "Community
   Considerations" section that indicates the dimensions upon which the
   proposer expects its community to be able to benefit by publication
   of this namespace, as well as how a general Internet user will be
   able to use the space if they care to do so.

   Potential considerations include:

      -  open assignment and use of identifiers within the namespace;

      -  open operation of resolution servers for the namespace
         (server);

      -  creation of software that can meaningfully resolve and access
         services for the namespace (client).

   [[ Editorial Note:
   It is acknowledged that, in many cases, the Namespace Considerations
   and Community Considerations are closely intertwined.  Further, the
   bulleted lists above (from RFC 3406) seems to be more related to the
   items in the registration template entitled "Identifier uniqueness
   considerations", "Identifier persistence considerations", "Process of
   identifier assignment", and "Process for identifier resolution" than
   to the primary objectives presented in the first paragraph above
   (also from RFC 3406).
   In fact, namespace registration documents seen so far duplicate in
   the registration template material from the "Community
   Considerations" that addresses the above bullets.
   Therefore: Should this specification now allow a combined section
   "Namespace and Community Considerations" that focuses on the
   (non-)utility of possible alternate namespace re-use and the
   *benefits* of an independent new namespace?
   ]]

4.4.3.  Security Considerations in Registration Documents

   According to the general procurements for RFCs, URN Namespace
   definition documents must include a "Security Considerations" section
   (cf. BCP 72 [RFC3552]).  That section has to identify the security
   considerations specific to the subject URN Namespace.  If the subject
   URN Namespace is based on an underlying namespace, the registration
   can include substantive security considerations described in
   specifications related to that particular namespace by reference to
   these documents.  For general security considerations regarding URN
   usage (and more generally, URI usage), for the sake of clarity and
   brevity, it should refer to the Security Considerations in STD 63

Hoenes                     Expires May 3, 2012                 [Page 12]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

   [RFC3986] and in the URN Syntax document
   [I-D.ietf-urnbis-rfc2141bis-urn].

4.4.4.  IANA Considerations in Registration Documents

   According to the general procurements for RFCs, URN Namespace
   definitions documents must include an "IANA Considerations" section
   (cf. BCP 26 [RFC5226]).  That section has to indicate that the
   document includes a URN Namespace registration that is to be entered
   into the IANA registry of Formal URN Namespaces.

   Registration documents for formal URN Namespaces will provide a
   particular, unique, desired NID string, and this will be assigned by
   the Standards/Protocol Action of the IESG that approves the
   publication of the registration document as an RFC.  RFC 2141bis
   [I-D.ietf-urnbis-rfc2141bis-urn] specifies that NID strings are ASCII
   strings that are interpreted in a case-insensitive manner, but the
   NID string SHALL be registered in the capitalization form preferred
   by the registrant.  The proposed NID string MUST conform with the
   <nid> syntax rule in Section 2.1 of RFC 2141bis
   [I-D.ietf-urnbis-rfc2141bis-urn] and it MUST adhere to the following
   additional constraints:

      -  not be an already-registered NID;

      -  not start with "X-" (see Section 4.1 above);

      -  not start with "urn-" (see Section 4.2 above);

      -  not start with "xy-", where xy is any combination of 2 ASCII
         letters (see NOTE below);

      -  be more than 2 characters long.

   NOTE: All two-letter combinations as well as two-letter combinations
   followed by "-" and any sequence of valid NID characters are reserved
   for potential use as countrycode-based NIDs for eventual national
   registrations of URN Namespaces.  The definition and scoping of rules
   for allocation of responsibility for such namespaces is beyond the
   scope of this document.
   Further, to avoid confusion, "urn" is not allowed as an NID string;
   IANA has permanently reserved this string to prohibit assignment.

   Registrations may be revised by updating the RFC through standard
   IETF RFC update processes.  In any case, a revised document, in the
   form of a new Internet-Draft, must be published, and the proposed
   updated template must be circulated on the urn-nid discussion list,
   allowing for a two-week [[ four-week ? ]] review period before
   pursuing RFC publication of the new document.

Hoenes                     Expires May 3, 2012                 [Page 13]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

5.  Security Considerations

   This document largely focuses on providing mechanisms for the
   declaration of public information.  Nominally, these declarations
   should be of relatively low security profile, however there is always
   the danger of "spoofing" and providing mis-information.  Information
   in these declarations should be taken as advisory.

6.  IANA Considerations

   This document outlines the processes for registering URN Namespaces,
   and has implications for the IANA in terms of registries to be
   maintained, as previously defined in RFC 3406 [RFC3406].  This
   document replaces RFC 3406; it contains a revised description for the
   management of the "Uniform Resource Names (URN) Namespaces" IANA
   Registry that uses the policy designation terms from BCP 26, RFC 5226
   [RFC5226], but does not introduce significant changes to the
   applicable procedures.

   All references there to the predecessor, [RFC3406], should be
   replaced by references to this document.
   We would appreciate a reorganization of the Registry web page to make
   the registration templates for Informal URN Namespaces directly
   linked from the main page; this would make the page /assignments/
   urn-informal.htm page dispensable (for persistency's sake, the web
   server should redirect requests to the /assignments/urn-namespaces
   page.

   Section 4.4.4 above describes the syntax rules for NIDs to which the
   registry needs to obey.  As pointed out in Section 4.4.4 above and in
   RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn], the string "urn" is
   permanently reserved and MUST NOT be assigned as an NID.

   In all cases of new namespace registration proposals, the IANA should
   provisionally assign the appropriate NID (informal or formal), as
   described throughout the body of this memo, once an IESG-designated
   expert has confirmed that the requisite registration process steps
   have been completed.  These registrations become permanent and can be
   made publicly available once the registration document has been
   approved by the IESG for publications as a Standards Track or
   Informational RFC.

Hoenes                     Expires May 3, 2012                 [Page 14]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

7.  Acknowledgements

   This document is heavily based on RFC 3406, the authors of which are
   cordially acknowledged.

   This document also been inspired by other recent documents that have
   updated important IANA registries, and the countless authors and
   contributors to these efforts are acknowledged anonymously.

   Several individuals in the URNbis working group have participated in
   the detailed discussion of this memo.  Particular thanks for detailed
   review comments and text suggestions go to Juha Hakala and Mykyta
   Yevstifeyev.

8.  References

8.1.  Normative References

   [I-D.ietf-urnbis-rfc2141bis-urn]
              Hoenes, A., "Uniform Resource Name (URN) Syntax",
              draft-ietf-urnbis-rfc2141bis-urn-01 (work in progress),
              October 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3339]  Klyne, G., Ed. and C. Newman, "Date and Time on the
              Internet: Timestamps", RFC 3339, July 2002.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

8.2.  Informative References

   [IANA]     IANA, "The Internet Assigned Numbers Authority",
              <http://www.iana.org/>.

   [IANA-URI] IANA, "URI Schemes Registry",
              <http://www.iana.org/assignments/uri-schemes/>.

   [IANA-URN] IANA, "Uniform Resource Names (URN) Namespace Registry",
              <http://www.iana.org/assignments/urn-namespaces/>.

Hoenes                     Expires May 3, 2012                 [Page 15]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

   [RFC2276]  Sollins, K., "Architectural Principles of Uniform Resource
              Name Resolution", RFC 2276, January 1998.

   [RFC2611]  Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
              "URN Namespace Definition Mechanisms", BCP 33, RFC 2611,
              June 1999.

   [RFC3305]  Mealling, M. and R. Denenberg, "Report from the Joint W3C/
              IETF URI Planning Interest Group: Uniform Resource
              Identifiers (URIs), URLs, and Uniform Resource Names
              (URNs): Clarifications and Recommendations", RFC 3305,
              August 2002.

   [RFC3401]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part One: The Comprehensive DDDS", RFC 3401, October 2002.

   [RFC3405]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Five: URI.ARPA Assignment Procedures", BCP 65,
              RFC 3405, October 2002.

   [RFC3406]  Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
              "Uniform Resource Names (URN) Namespace Definition
              Mechanisms", BCP 66, RFC 3406, October 2002.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.

   [RFC4020]  Kompella, K. and A. Zinin, "Early IANA Allocation of
              Standards Track Code Points", BCP 100, RFC 4020,
              February 2005.

   [RFC4395]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
              Registration Procedures for New URI Schemes", BCP 35,
              RFC 4395, February 2006.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

Appendix A.  URN Namespace Definition Template

   Definition of a URN Namespace is accomplished by completing the
   following information template.
   Apart from providing a mechanism for disclosing the structure of the
   URN Namespace, this information is designed to be useful for

Hoenes                     Expires May 3, 2012                 [Page 16]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

   -  entities seeking to have a URN assigned in a namespace (if
      applicable) and

   -  entities seeking to provide URN resolvers for a namespace (if
      applicable).

   This is particularly important for communities evaluating the
   possibility of using a portion of an existing URN Namespace rather
   than creating their own.

   Applications for Formal URN Namespaces must also document "Namespace
   Considerations", "Community Considerations", "Security
   Considerations", and "IANA Considerations", as described in
   Section 4.4.

   Information in the template is as follows (text in curly braces is
   tutorial and should be removed from filled-in templates):

   Namespace ID:

      { If request is for an Informal NID, indicate so; the number will
      be assigned by IANA.  In the case of a Formal NID registration,
      regularly a particular NID string will be requested. }

   Registration Information:

      { This is information to identify the particular version of
      registration information: }
      -  version number:
         { starting with 1, incrementing by 1 with each new version }
      -  date:
         { date submitted to the IANA or date of approval of
         registration document, using the format outlined in "Date and
         Time on the Internet: Timestamps", [RFC3339]: YYYY-MM-DD }

   Declared registrant of the namespace:

      -  Registering organization:
           Name: { ... }
           Address: { ... }
      -  Designated contact person:
           Name: { ... }
         { Address: ...
           (at least one of: Email, Phone, Postal address) }

Hoenes                     Expires May 3, 2012                 [Page 17]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

   Declaration of syntactic structure of NSS part:

      [[ Editorial Note: In the past, there has been iterated trouble in
      tentative registration documents with confusion between entire URN
      syntax and NSS syntax (only).  Since the "urn:" prefix is fixed
      and the NID is fully determined by the "Namespace ID" clause
      above, in order to avoid error prone duplication, this version of
      the template tentatively restricts this clause to the NSS
      (namespace specific string) part of the new URNs. ]]

      {
      This section should outline any structural features of identifiers
      in this namespace.  At the very least, this description may be
      used to introduce terminology used in other sections.  This
      structure may also be used for determining realistic caching/
      shortcuts approaches; suitable caveats should be provided.  If
      there are any specific character encoding rules (e.g., which
      character should always be used for single-quotes), these should
      be listed here.

      Answers might include, but are not limited to:
      -  the structure is opaque (no exposition);
      -  a regular expression for parsing the identifier into
         components, including naming authorities;
      -  formal syntax of the NSS, preferably in ABNF (STD 68
         [RFC5234]).
      }

   Relevant ancillary documentation:

      {
      This section should list any RFCs, standards, or other published
      documentation that defines or explains all or part of the
      namespace structure.

      Answers might include, but are not limited to:
      -  RFCs that outline the syntax of the namespace;
      -  other documents of the defining community (e.g., ISO) that
         outline the syntax of the identifiers in the namespace;
      -  explanatory material that introduces the namespace.
      }

   Conformance with URN Syntax:

      [[ Editorial Note: This clause moved into vicinity of "syntax". ]]

      {
      This section should outline any special considerations required

Hoenes                     Expires May 3, 2012                 [Page 18]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

      for conforming with the URN syntax.  This is particularly
      applicable in the case of legacy naming systems that are used in
      the context of URNs.

      For example, if a namespace is used in contexts other than URNs,
      it may make use of characters that are reserved in the URN syntax.

      This section should flag any such characters, and outline
      necessary mappings to conform to URN syntax.  Normally, this will
      be handled by percent-encoding the symbol.
      }

   Rules for Lexical Equivalence of NSS part:

      [[ Editorial Note: This clause moved into vicinity of "syntax". ]]

      [[ Editorial Note: In the past, there has been iterated trouble in
      tentative registration documents with regard to what rules can be
      imposed for lexical equivalence.  Since the "urn:" prefix and the
      NID part both are invariably case-insensitive per RFC 3986 and RFC
      2141[bis], in order to avoid repeated confusion, this version of
      the template tentatively restricts this clause to only the NSS
      part of the new URN Namespace definition documents. ]]

      {
      If there are particular algorithms for determining equivalence
      between two identifiers in the underlying namespace (and hence, in
      the URN string itself), rules can be provided here.

      Some examples include:
      -  equivalence between hyphenated and non-hyphenated groupings in
         the identifier string;
      -  equivalence between single-quotes and double-quotes;
      -  namespace-defined equivalences between specific characters,
         such as "character X with or without diacritic marks".

      Note that these are not normative statements for any kind of best
      practice for handling equivalences between characters; they are
      statements limited to reflecting the namespace's own rules.
      }

   Identifier uniqueness considerations:

      {
      This section should address the requirement that URN identifiers
      be assigned uniquely -- they are assigned to at most one resource,
      and are not reassigned.

Hoenes                     Expires May 3, 2012                 [Page 19]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

      (Note that the definition of "resource" is fairly broad; for
      example, information on "Today's Weather" might be considered a
      single resource, although the content is dynamic.)

      Possible answers include, but are not limited to:
      -  exposition of the structure of the identifiers, and
         partitioning of the space of identifiers amongst assignment
         authorities that are individually responsible for respecting
         uniqueness rules;
      -  identifiers are assigned sequentially;
      -  information is withheld; that is, the namespace is opaque.
      }

   Identifier persistence considerations:

      {
      Although non-reassignment of URN identifiers ensures that a URN
      will persist in identifying a particular resource even after the
      "lifetime of the resource", some consideration should be given to
      the persistence of the usability of the URN.  This is particularly
      important in the case of URN Namespaces providing global
      resolution.

      Possible answers include, but are not limited to:
      -  quality of service considerations.
      }

   Process of identifier assignment:

      {
      This section should detail the mechanisms and/or authorities for
      assigning URNs to resources.  It should make clear whether
      assignment is completely open, or if limited, how to become an
      assigner of identifiers, and/or get one assigned by existing
      assignment authorities.

      Answers could include, but are not limited to:
      -  assignment is completely open, following a particular
         algorithm;
      -  assignment is delegated to authorities recognized by a
         particular organization (e.g., the Digital Object Identifier
         Foundation controls the DOI assignment space and its
         delegation);
      -  assignment is completely closed (e.g., for a private
         organization).
      }

Hoenes                     Expires May 3, 2012                 [Page 20]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

   Process for identifier resolution:

      {
      If a namespace is intended to be accessible for global resolution,
      it must be registered in an RDS (Resolution Discovery System, see
      RFC 2276 [RFC2276]) such as the DDDS (see RFC 3401 [RFC3401]).
      Resolution then proceeds according to standard URI resolution
      processes, and the mechanisms of the RDS.  What this section
      should outline is the requirements for becoming a recognized
      resolver of URNs in this namespace (and being so listed in the RDS
      registry).

      Answers may include, but are not limited to:
      -  the namespace is not listed with an RDS, this is not relevant;
      -  resolution mirroring is completely open, with a mechanism for
         updating an appropriate RDS;
      -  resolution is controlled by entities to which assignment has
         been delegated.
      }

   Validation mechanism:

      {
      Apart from attempting resolution of a URN, a URN Namespace may
      provide mechanisms for "validating" a URN -- i.e., determining
      whether a given string is currently a validly-assigned URN.  There
      are 2 issues here: 1) users should not "guess" URNs in a
      namespace; 2) when the URN Namespace is based on an existing
      identifier system, it may not be the case that all the existing
      identifiers are assigned on Day 0.  The reasonable expectation is
      that the resource associated with each resulting URN is somehow
      related to the thing identified by the original identifier system,
      but those resources may not exist for each original identifier.
      For example, even if a telephone number-based URN Namespace was
      created, it is not clear that all telephone numbers would
      immediately become "valid" URNs, that could be resolved using
      whatever mechanisms are described as part of the namespace
      registration.

      Validation mechanisms might be:
      -  a syntax grammar;
      -  an on-line service;
      -  an off-line service.
      }

Hoenes                     Expires May 3, 2012                 [Page 21]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

   Scope:

      {
      This section should outline the scope of the use of the
      identifiers in this namespace.  Apart from considerations of
      private vs. public namespaces, this section is critical in
      evaluating the applicability of a requested NID.  For example, a
      namespace claiming to deal with "social security numbers" should
      have a global scope and address all social security number
      structures (unlikely).  On the other hand, at a national level, it
      is reasonable to propose a URN Namespace for "this nation's social
      security numbers".
      }

Appendix B.  Illustration

B.1.  Example Template

   [[ Editorial Note: Do we really need this any more?
   Such an almost-concrete example likely contradicts current IESG
   policy on usage of examples in RFCs. ]]

   The following example is provided for the purposes of illustrating
   the URN NID template described in Appendix A.  Although it is based
   on a hypothetical "generic Internet namespace" that has been
   discussed informally within the URN WG, there are still technical and
   infrastructural issues that would have to be resolved before such a
   namespace could be properly and completely described.

   Namespace ID:

      To be assigned

   Registration Information:

      -  version number:  1
      -  date:  <when submitted>

   Declared registrant of the namespace:

      -  Registering organization:
         Name:      Thinking Cat Example Enterprises
         Postal:    1 ThinkingCat Way
                    Trupville, NewCountry

Hoenes                     Expires May 3, 2012                 [Page 22]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

      -  Designated contact person:
         Name:      L. Daigle
         Email:     leslie@thinkingcat.example

   Declaration of syntactic structure of NSS part:

      The namespace specific string structure is as follows:

         <FQDN>:<assigned string>

      where FQDN is a fully-qualified domain name, and the assigned
      string is conformant to URN syntax requirements.

   Relevant ancillary documentation:

      Definition of domain names, found in:

      P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", STD 13,
      RFC 1034, November 1987.

      P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
      STD 13, RFC 1035, November 1987.

   Conformance with URN Syntax:

      No special considerations.

   Rules for Lexical Equivalence of NSS part:

      FQDNs are case-insensitive.  Thus, the leading portion of the URN
      up to the colon after the FQDN is case-insensitive for matches.
      The remainder of the identifier must be considered case-sensitive.

   Identifier uniqueness considerations:

      Uniqueness is guaranteed as long as the assigned string is never
      reassigned for a given FQDN, and that the FQDN is never
      reassigned.

      N.B.: operationally, there is nothing that prevents a domain name
      from being reassigned; indeed, it is not an uncommon occurrence.
      This is one of the reasons that this example makes a poor URN
      namespace in practice, and is therefore not seriously being
      proposed as it stands.

Hoenes                     Expires May 3, 2012                 [Page 23]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

   Identifier persistence considerations:

      Persistence of identifiers is dependent upon suitable delegation
      of resolution at the level of "FQDN"s, and persistence of FQDN
      assignment.

      Same note as above.

   Process of identifier assignment:

      Assignment of these URNs is delegated to individual domain name
      holders (for FQDNs).  The holder of the FQDN registration is
      required to maintain an entry (or delegate it) in the DDDS.
      Within each of these delegated name partitions, the string may be
      assigned per local requirements.

      E.g., urn:urn-<assigned number>:thinkingcat.example:001203

   Process for identifier resolution:

      Domain name holders are responsible for operating or delegating
      resolution servers for the FQDN in which they have assigned URNs.

   Validation mechanism:

      None specified.

   Scope:

      Global.

B.2.  Registration steps in practice

   The key steps for registration of informal or formal namespaces
   typically play out as follows:

   A) Informal NID:

      1.  Complete the registration template.  This may be done as part
          of an Internet-Draft.

      2.  Communicate the registration template to urn-nid@ietf.org for
          technical review -- as an email with a pointer to the
          submitted I-D or inline text containing the template.

      3.  Update the registration template (and/or document) as
          necessary from comments, and repeat steps 2 and 3 as
          necessary.

Hoenes                     Expires May 3, 2012                 [Page 24]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

      4.  Once comments have been addressed (and the review period has
          expired), send a request to IANA with the revised registration
          template.

   B) Formal NID:

      1.  Write an Internet-Draft describing the namespace and include
          the registration template, duly completed.  Be sure to include
          "Namespace Considerations", "Community Considerations",
          "Security Considerations", and "IANA Considerations" sections,
          as described in Section 4.4.

      2.  Submit the Internet-Draft, and send a pointer to the I-D
          (perhaps using a copy of the I-D announcement) to
          urn-nid@ietf.org in order to solicit technical review.

      3.  Update the Internet-Draft as necessary from comments, and
          repeat steps 2 and 3 as needed.

      4.  If the Internet-Draft is the product of a working group in the
          IETF, follow the usual WG process to forward the document to
          the IESG for publication as an RFC.  Otherwise, find a
          sponsoring Area Director willing to guide the draft through
          the IESG.  The IESG (or the IETF at large in case an IETF-wide
          last call is deemed necessary) may request further changes
          (submitted as I-D revisions) and/or direct discussion to
          designated working groups, area experts, etc.

      5.  The IESG evaluation process includes a review by IANA, and if
          the IESG approves the document for publication as an RFC, IANA
          processing of the document will follow the regular work-flow
          between the RFC Editor and IANA.  This way, the NID
          registration will be made public by IANA when the RFC is
          published.

Appendix C.  Changes from RFC 3406

C.1.  Essential Changes since RFC 3406

   [ RFC Editor: please remove the Appendix C.1 headline and all
   subsequent subsections of Appendix C starting with Appendix C.2. ]

   T.B.D. (after consolidation of this memo)

C.2.  Changes from RFC 3406 to URNbis WG Draft -00

Hoenes                     Expires May 3, 2012                 [Page 25]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

   o  Abstract: rewritten entirely;

   o  Section 1 (Introduction): added historical RFC information;

   o  Section 1.1 (Requirements Language): added;

   o  Section 3.1: added Note that challenges the utility of
      Experimental namespaces and raises question of whether formal
      "provisional" registrations would be useful;

   o  Section 4: text expanded and updated; background material added;
      added Note to challenge IANA website practices;

   o  Section 4.2 ff: changed "home" of URN-NID registration discussion
      list (it already had been moved to the IETF Secretariat servers);

   o  Section 4.2: added Note to challenge the 2-week review period; in
      current practice, that is almost always exceeded, and some regard
      it as too short;

   o  Section 4.3: largely clarified procedures as they happen in
      practice; adapted language for conformance with RFC 5226; use new
      home of URN-NID (as mentioned above); the registration template
      (Appendix A) now "SHOULD" be used;

   o  Section 4.3: split off new Section 4.4 on Registration Documents,
      because registrants essentially are encouraged to follow these
      guidelines for Informal namespaces as well, as far as practical;
      replaced "RFC" by "Registration Document"; Section 4.4 is
      subdivided for all mandatory sections;

   o  Section 4.4.1: made requirements a "MUST";

   o  Sections 4.4.1 and 4.4.2: added common Note that challenges the
      need to split Namespace and Community Considerations, based on
      observed problems in practice to separate the topics, and pointing
      to overlap with clauses in the registration template due to
      bullets listed that are not so clearly related to the headlines
      under which they appear; suggestion is to avoid duplication, place
      factual stuff into the template and focus on rationale in these
      Considerations, perhaps in a common section;

   o  Section 4.4.3: added discussion of Security Considerations
      section; advice is to focus on namespace-specific considerations
      and refer to the SecCons in the "generic" RFCs for the general
      issues;

Hoenes                     Expires May 3, 2012                 [Page 26]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

   o  Section 4.4.4: amended discussion of IANA Considerations section;
      this tries to reflect standing practice and codifies that Formal
      NIDs are generally proposed by the registrant; added Note that
      "urn" is permanently reserved and MUST NOT be assigned as a NID,
      to avoid confusion (as also specified in RFC 2141bis draft); wrt
      registration maintenance: got rid of wrong reference in RFC 3406
      (to RFC 2606);

   o  Section 6 (IANA Considerations): updated and rephrased description
      of the role of this document, including a sketch of the history;
      added teat that tries to precisely describe what is expected from
      IANA on approval of this draft; added text on procedures and
      suggest a provisional assignment practice upon "thumbs-up" of the
      IANA Expert to protect prospective registrants from collateral
      damage on NID precedence in case the document suffers from delays
      unrelated to the registration template before it eventually gets
      approved;

   o  Section 7 (Acknowledgements): added;

   o  References: Updated and amended references; added pointers to
      chartered URNbis work items; removed entirely outdated example
      material related to legacy documents;

   o  Appendix A and B.1: added words on Security Considerations
      section;

   o  Appendix A (Registration Template): clarified role of text
      snippets in the Template: hint and commentary now all enclosed in
      curly braces, with not that these parts shall be removed when
      filling in the tempalte; indicate that Formal NIDs are normally
      proposed by registrant; changed date/time ref. from ISO 8601 to
      RFC 3339; use inherited term "percent-encoding";

   o  Appendix A -- structure: moved formal clauses on Conformance with
      URN Syntax and Rules for Lexical Equivalence to vicinity of
      namespace specific syntax clause, to which these are closely
      related;

   o  Appendix A -- changes of clauses: the Declaration of syntactic
      structure and Rules for Lexical Equivalence clauses now
      tentatively have been restricted to the NSS part only; this change
      is described in NOTEs and motivated by the observation of repeated
      confusion in past and present registration documents, which
      hopefully can be avoided (and the job of the Expert and reviewers
      made easier) by leaving discussion of the invariate parts that
      cannot be re-specified there at the single place where they belong
      to: the NID is fully specified in the initial clause, rules for

Hoenes                     Expires May 3, 2012                 [Page 27]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

      the NID and the URI scheme name "urn" are inherited from RFC
      2141[bis] and RFC 3986, respectively, and hence the new clause
      descriptions avoid conflict by taking these components out of
      scope of these clauses;

   o  Appendix B.1 (Example Template): facelifted a bit; concerns with
      IESG policy on examples in RFCs raised in a NOTE;

   o  Appendix B.2 (Registration steps in practice): updated and
      clarified description of procedure, in alignment to current
      practice;

   o  Appendix C: removed "Changes from RFC 2611"; added this change
      log;

   o  General: numerous editorial changes and enhancements, following
      contemporary RFC style.

Appendix D.  Open Issues

   Discuss consequences of RFC 2141bis (once consensus is achieved); if
   proposal for fragment part is adopted, details need to be described
   per namespace that wants to adopt these possibilities, and maybe the
   registration template needs a new clause where this will be specified
   -- or the information has to be assigned to existing clauses.

   More elaboration on Services.  Since RFC 2483 is considered outdated,
   but RFC 2483bis not yet a URNbis work item, we might need a registry
   for URN Services (initially populated from RFC 2483) that can be
   referred to in namespace registration documents, thus avoiding
   normative dependencies on a future RFC 2483bis.

   Do we actually need Experimental Namespaces?

   The syntax of the NID strings for the various NID types is given in
   an informal manner (as has been done in RFC 3406); is it worth the
   effort to introduce ABNF for this purpose?

   Increase review/timeout periods for urn-nid list and IANA experts to
   4 weeks?

   Clarification of the desired content of the "Namespace
   Considerations" and "Community Considerations" sections in
   registration documents.  Shall we admit a combined section for both
   topics? (so far supported by 2 postings) Cf. the NOTEs in Sections
   4.4.1 and 4.4.2 for more details.

   Shall other strings than "urn" also be 'reserved' in the NID
   registry? (e.g. "uri", "url", "urc", "example", ...)

Hoenes                     Expires May 3, 2012                 [Page 28]
Internet-Draft     URN Namespace Definition Mechanisms      October 2011

   Do we still need Appendix B.1 ?  (There are lots of real-life
   examples now!)

   Also see the Editorial Notes interspersed in the body of this draft.

Author's Address

   Alfred Hoenes
   TR-Sys
   Gerlinger Str. 12
   Ditzingen  D-71254
   Germany

   EMail: ah@TR-Sys.de

Hoenes                     Expires May 3, 2012                 [Page 29]