IETF URNbis WG                                            A. Hoenes,
URNBIS                                               P. Saint-Andre, Ed.
Internet-Draft                                                    TR-Sys                                       Cisco Systems, Inc.
Obsoletes: 3406 (if approved)                           October 19, 2012                                  L. Daigle
Intended status: BCP                                        D. van Gulik
Expires: April 22, May 31, 2013

            Defining                                        R. Iannella
                                                            P. Faltstrom
                                                       November 27, 2012

           Uniform Resource Name (URN) Namespaces
              draft-ietf-urnbis-rfc3406bis-urn-ns-reg-03 Namespace Definitions
               draft-ietf-urnbis-rfc3406bis-urn-ns-reg-04

Abstract

   RFC 2141bis formalizes

   This document supplements 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 Name (URN) syntax
   specification by defining the registry to the related
   documents and the particularities concept of specific namespaces, a URN namespace, as
   described in these Namespace registration documents.

   This RFC serves well as a design guideline
   mechanisms 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 defining and the essential content of registering such documents. namespaces.  This
   document supersedes and replaces obsoletes RFC 3406.

Discussion

   Discussion of this memo utilizes the urn@ietf.org mailing list.
   [[ RFC-Editor: this clause to be deleted before RFC publication ]]

Status of This this Memo

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

   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 April 22, May 31, 2013.

Copyright Notice

   Copyright (c) 2012 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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirement Language and Terminology . .  3
   2.  Discussion Venue . . . . . . . . .  5
   2.  What is a URN Namespace? . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . .  6
   3.  URN Namespace (Registration) Types . . . . . . . . . . . . . .  8
     3.1.  Experimental Namespaces . . . . . .  4
   4.  What is a URN Namespace? . . . . . . . . . . .  8
     3.2.  Informal Namespaces . . . . . . . .  4
   5.  URN Namespace Types  . . . . . . . . . . .  8
     3.3.  Formal Namespaces . . . . . . . . . .  5
     5.1.  Formal Namespaces  . . . . . . . . . .  8
   4.  URN Namespace Registry: Processes for Registration and
       Update . . . . . . . . . .  5
     5.2.  Informal Namespaces  . . . . . . . . . . . . . . . . . . 10
     4.1.  Experimental Namespaces: No Registration .  6
   6.  Defining a URN Namespace . . . . . . . . 11
     4.2.  Informal Namespaces . . . . . . . . . . .  7
     6.1.  Formal Namespaces  . . . . . . . . 12
     4.3.  Formal Namespaces . . . . . . . . . . . .  7
       6.1.1.  Syntax . . . . . . . . 13
     4.4.  Registration Documents . . . . . . . . . . . . . . . .  7
       6.1.2.  Specification  . . 14
       4.4.1.  Namespace Considerations in Registration Documents . . 14
       4.4.2.  Community Considerations in Registration Documents . . 15
       4.4.3.  Security Considerations in Registration Documents . . 16
       4.4.4.  IANA Considerations in Registration Documents . . . . 16
   5.  Security Considerations . . . . . . . .  8
     6.2.  Informal Namespaces  . . . . . . . . . . . 17
   6.  IANA Considerations . . . . . . . .  8
   7.  Registering a URN Namespace  . . . . . . . . . . . . . 17
   7.  Acknowledgements . . . .  9
     7.1.  Formal Namespaces  . . . . . . . . . . . . . . . . . . . .  9
     7.2.  Informal Namespaces  . . . . . . . . . . . . . . . . . . . 19  9
   8.  References  URN Namespace Definition Template  . . . . . . . . . . . . . . 10
   9.  Security Considerations  . . . . . . . . . . . . 19
     8.1.  Normative References . . . . . . . 14
   10. IANA Considerations  . . . . . . . . . . . . 19
     8.2.  Informative References . . . . . . . . . 14
   11. References . . . . . . . . . 20
   Appendix A.  URN Namespace Definition Template . . . . . . . . . . 21
     A.1.  Annotated URN Namespace Definition Template . . . . . . . 21
     A.2.  Plain URN Namespace Definition Template (Informative) 15
     11.1. Normative References . . 27
   Appendix B.  Summary of Registration Steps (Informative) . . . . . 28
   Appendix C.  Changes from RFC 3406 (Informative) . . . . . . . . . 29
     C.1.  Essential Changes since RFC 3406 . . . 15
     11.2. Informative References . . . . . . . . . . . . . . . . . 29
     C.2. . 15
   Appendix A.  Changes from RFC 3406 to URNbis WG Draft -00 . . . . . . . 29
     C.3.  Changes from URNbis WG I-D -00 to -01 . . . . . . . . . 15
   Authors' Addresses . . . 32
     C.4.  Changes from URNbis WG I-D -01 to -02 . . . . . . . . . . 32
     C.5.  Changes from URNbis WG I-D -02 to -03 . . . . . . . . . . 32 . 15

1.  Introduction

   A Uniform Resource Names (URNs) are identifiers bound to resources with
   the objective Name (URN) is a Uniform Resource Identifier (URI)
   that is intended to provide location-independent identification of these
   resources as well serve as longevity a persistent, location-independent
   resource identifier.  The general class of reference. URNs are part is differentiated
   from all other URIs through the use of the
   larger 'urn' URI scheme.

   This document supplements the Uniform Resource Identifier (URI) family (see the joint W3C/
   IETF memorandum, RFC 3305 [RFC3305], and the IETF STD 66, RFC 3986
   [RFC3986]), with Name (URN) syntax
   specification by defining (1) the specific goal concept of persistent binding names to
   resources.

   The a URN scheme formalized in RFC 2141bis
   [I-D.ietf-urnbis-rfc2141bis-urn] structures and organizes the
   entirety of URNs into namespace, (2) a hierarchy that divides the set of possible
   URNs into "URN Namespaces" that can be individually defined, managed,
   mechanism for defining such namespaces and (optionally) further subdivided.  URN Namespaces in particular
   serve to map existing associating each namespace
   with a public identifier systems into the URN system (called a Namespace ID or "NID"), and
   thereby make available generic, network-based resolution services (3)
   procedures for registering such namespaces with the identified resources (documents, artifacts, abstract concepts,
   and other objects) and their metadata.

   There are Internet Assigned
   Numbers Authority (IANA).

   This document rests on two assumptions that are key to this document:

   Assumption #1: assumptions:

   1.  Assignment of a URN is a managed process.

      I.e., not all strings

       A string that conform conforms to the URN syntax are is not necessarily a
       valid URNs.  A URN, because a URN is needs to be assigned according to the
       rules of a particular namespace (in terms of syntax, semantics,
       and process).

   Assumption #2:

   2.  The space of URN Namespaces namespaces is itself managed.

      I.e., not all syntactically correct URN Namespace identifiers (per

       A string in the namespace identifier slot of the URN syntax definition) designate is
       not necessarily a valid URN Namespaces.  A URN
      Namespace must have a well recognized definition namespace identifier, because in
       order to be
      valid.

   To actually draw benefits from this unification (structured embedding
   of existing namespaces into the URN framework), URN Namespaces have
   common design considerations, they need to be specified in valid a
   comparable manner, and their Namespace Identifiers (NIDs) need namespace needs to be
   centrally registered, so that naming conflicts are avoided defined and
   implementers of services can follow a structured approach registered
       in support
   of various namespaces, guided by the registry to the related
   documents and accordance with the particularities rules of specific namespaces, as
   described this document.

   URN namespaces were originally defined in these [RFC2611], which was
   obsoleted by [RFC3406].  Based on experience with defining and
   registering URN Namespace registration documents.

   The primary purpose namespaces since that time, the goal of this document
   is to outline a mechanism for
   explicit specify URN Namespace definition, associating it namespaces with an identifier
   (called a "Namespace ID", or NID).  To this end, this RFC defines the
   requirements for URN NID specification documents and provides a
   registration template, which is to be registered with smallest reasonable set of
   changes from [RFC3406].

   Although on the Internet
   Assigned Numbers Authority (IANA) [IANA] surface it might appear that this document is
   significantly different from [RFC3406], in general it only modifies
   the URN Namespaces
   registry maintained at [IANA-URN].  However, to give additional
   guidance to prospective stakeholders / designers order of URN Namespaces in
   fulfiling presentation, with the requirements for registration, this document also
   elaborates on generic considerations and design choices for the
   establishment intent of URN Namespaces.

   The URN Namespace definition and registration mechanisms originally
   have been specified in BCP 33, RFC 2611 [RFC2611], which has been
   obsoleted by BCP 66, RFC 3406 [RFC3406].  Guidelines making it easier for documents
   prescribing IANA procedures have been revised as well over the years,
   people to define and at the time of this writing, BCP 26, RFC 5226 [RFC5226] is register URN namespaces.  However, the
   normative document.  This document only
   major substantive change is a revision of RFC 3406 based on removing the revised specification category of URNs experimental
   namespaces, in accorance with [RFC6648].

   If approved, this document will obsolete RFC 2141bis
   [I-D.ietf-urnbis-rfc2141bis-urn] and RFC 5226. 3406.

2.  Discussion Venue

   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 discussion venue 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 mailing list of registration in a global NID directory, such as that
   proposed by the DDDS system [RFC3401], is necessary.  See [RFC3405]
   for information on obtaining registration in the DDDS global NID
   directory.  RFC 2141bis establishes an IANA registry URNBIS
   WG; visit <https://www.ietf.org/mailman/listinfo/urn> for URN
   services, such that registration documents can unambiguously identify
   such services and discuss their applicability to the particular URN
   Namespace.

1.1.  Requirement Language
   subscription and archive information.

3.  Terminology

   When spelled in all-capitals as

   Several important terms used in this paragraph, document are defined in the URN
   syntax specification [I-D.saintandre-urnbis-2141bis].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP 14
   [RFC2119].  In this
   document, these key words describe requirements for the process to be
   followed and the content to be provided in URN 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 lower case, e.g., to designate a (standard or non-
   standard) identifier system on which a URN Namespace is based.

2.

4.  What is a URN Namespace?

   For the purposes of URNs, a "namespace" is a collection of uniquely-
   assigned identifiers.  That is, the unique
   identifiers that are not ever consistently assigned according to more than one resource.  These resources may be stable (e.g., a
   doctoral dissertation or common
   definition.

   The uniqueness constraint means that an abstract concept of a protocol) or
   dynamic (e.g., a continuously evolving web site of a periodical or a
   specific protocol parameter registry subject to additions and
   maintenance).  If the identified resource is a metadata record, such
   record may describe several objects (such as two versions of a book)
   or a collection of objects (such as a periodical with, say, monthly
   issues); in this case, these subordinate objects are not the
   identified resources.  For each namespace, it must be clear what the
   identified resources are; if identifier within the
   namespace is heterogenous in this
   respect, the registration and resolution systems must unambiguously
   designate the kind of identified resource, for each identifier never assigned in the namespace.  Once assigned, URNs are to more than one resource and never re-assigned re-
   assigned to a different resource.  A resource (however, a single resource, however, may resource can have
   more than one URN assigned to it -- within a particular Namespace or among
   different Namespaces -- for different purposes, since purposes).

   The consistent assignment constraint means that an identifier within
   the Namespaces
   are not mutually exclusive.

   Such abstract namespace might be defined is assigned by some pre-established
   (standard an organization or non-standard) identifier system in accordance with a
   process that is always followed.

   The common definition constraint means that can be made
   "network-actionable" by embedding it into the URN framework using syntax for
   identifiers within the namespace and the process for assigning such
   identifiers are clearly defined in a
   specific URN Namespace. specification.

   A URN Namespace itself has an identifier namespace is identified by a particular designator (which
   syntactically follows the 'urn' scheme name) in order to:
   -  ensure

   o  Ensure the global uniqueness of URNs,
   -  (where desired) URNs.
   o  Optionally provide a cue for regarding the structure of URNs assigned
      within a namespace.

   With regard to global uniqueness, using different designators for
   different collections of identifiers ensures that no two URNs will be
   the identifier. same for different resources (since each collection is required
   to uniquely assign each identifier).  For example, many instance, some 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
   systems, and the two collections (and making these designators an
   intrinsic syntactic part of URNs) ensures that no two URNs will be namespace identifier differentiates between the same for different resources (since each collection is required
   resulting URNs.

   With regard to uniquely assign each identifier).

   The the structure of URNs assigned within a namespace, 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., a publishing community, an association of
   booksellers,
   protocol developers, technology-specific vendor groups, developers of particular application protocols, etc.); they
   therefore these issues are beyond the scope of the IETF URN work.

   If a namespace contains structured resources, per RFC 2141bis
   [I-D.ietf-urnbis-rfc2141bis-urn] syntax and the designers of a related
   rules regarding URN
   Namespace namespaces in general.

   URN namespaces inherit certain rights and responsibilities,
   including:

   o  They uphold the implementers general principles of the related resolution systems have
   available three options for the Namespace to support a well-managed URN namespace
      by providing persistent identification of resources and resolution unique
      assignment of component resources:

   a.  A Namespace identifier strings.
   o  They can choose to assign individual identifiers
       (Namespace Specific String, NSS) to some or all components be registered in global registration services.

5.  URN Namespace Types

   There are two types of a
       structured resource that is also named URN namespace: formal and informal.  These are
   distinguished by the identifier system.
       This method is independent expected level of service, the Internet media types information
   required to define the
       resolution system(s) namespace, and the procedures for
   registration.  To date, the Namespace can provide.  This is vast majority of the
       preferred method.  However, there may be rules for registered
   namespaces have been formal, so this document concentrates on formal
   namespaces.

   Note: [RFC3406] defined a pre-existing
       identifier system (that is going to be made accessible via URNs)
       and objectives for third type of "experimental namespaces:,
   denoted by prefixing the NSS format desired that effectively
       prohibit such namespace identifier assignments; in such cases, with the
       Namespace designers cannot adopt string "X-".
   Consistent with [RFC6648], this method.

   b.  A Namespace can choose to provide a resolution system that
       interprets specification removes the 'component' ("c=") directive that
   experimental category.

5.1.  Formal Namespaces

   A formal namespace can be
       incorporated requested, and IETF review sought, in cases
   where the <query> part publication of URI references to URNs (see
       [I-D.ietf-urnbis-rfc2141bis-urn]).  This way, only the basic
       resources are assigned an NSS -- which will simplify the
       identifier assignment/registration processes/systems for the
       namespace, or even be dictated by existing processes/systems -- NID proposal and the URN resolvers for the Namespace can make use underlying
   namespace will provide benefit to some subset of
       additional information captured from users on the owners of
   Internet.  That is, a formal NID proposal, if accepted, needs to be
   functional on and with the individual
       resources (in any way global Internet, not limited to users in
   communities or networks not connected to the Internet.  For example,
   consider a NID that is proper meant for the namespace).  This
       method is independent naming of physics research; if that
   NID request required that the Internet media types user use a proprietary network or
   service that will be
       used was not at all open to return the URN resolution results for such Namespace, and
       as such allows general Internet user, then
   it would make a poor request for stable assigned names yet a flexible, perhaps
       evolving choice formal NID.  The intent is that,
   while the community of media types provided by those who may actively use the resolution
       system(s).

   c.  A Namespace names assigned
   within that tightly controls NID may be small (but no less important), the media types provided by
       particular resolution services might specify how resolution
       clients can make potential
   use of <fragment> identifiers contained in URI
       references names within that NID is open to URNs of any user on the Internet.

   It is expected that Namespace (see
       [I-D.ietf-urnbis-rfc2141bis-urn]) formal NIDs may be applied to pick namespaces where
   some aspects are not fully open.  For example, a component resource
       from namespace might make
   use of a fee-based, privately managed, or proprietary registry for
   assignment of URNs in the media returned by namespace.  However, it may still provide
   benefit to some Internet users if the URN service.  Since per STD 66
       [RFC3986] <fragment> identifiers of URIs are evaluated at services associated have
   openly- published access protocols.

   In addition to the
       client side basic information specified in the namespace
   definition template (see Section 8), a manner specific formal namespace request needs
   to each media type (if
       applicable at all), this method depends on be accompanied by documented considerations of the specific
       capabilities need for a new
   namespace and of the media types used.

   Namespaces specified prior to RFC 2141bis are constricted to method
   a.  Future Namespace definitions MUST document community benefit from formally establishing the methods applicable
   to it and available via its resolvers.

   This document outlines
   proposed URN namespace.

   Additionally, since the processes by which a collection of
   identifiers satisfying certain constraints (uniqueness goal of assignment,
   etc.) can become a bona fide URN Namespace by obtaining a NID.  In a
   nutshell, URNs is to provide persistent
   identification, a template for formal namespace request needs to give some
   consideration as to the definition longevity and maintainability of the Namespace is completed
   for deposit
   namespace.  Possible factors to consider with IANA, and regard to an
   organization that will assign URNs within a NID is assigned.  The details of namespace include the
   process
   following:

   o  It ought to demonstrate stability and possibilities for NID strings are outlined below.

3.  URN Namespace (Registration) Types

   There are three categories (types) of the ability to maintain the
      URN Namespaces defined here,
   distinguished by expected level of service and required procedures
   for registration.  Registration processes namespace for each of these Namespace
   types are given a long time; absent such evidence, it ought to
      be clear how the namespace can remain viable if the organization
      can no longer maintain the namespace.
   o  It ought to demonstrate competency in Section 4.  In both this Section and Section 4
   these categories are ordered by increasing relevance/importance for name assignment.  This will
      improve the Internet and, accordingly, increasing strenght likelihood of requirements
   for persistence (e.g. to minimize the definition and registration processes.

3.1.  Experimental Namespaces

   These are
      likelihood of conflicts);
   o  It ought to commit to not explicitly registered with IANA.

   No provision is made for avoiding collision re-assigning existing names and to
      allowing old names to continue to be valid, even if the owners or
      assignees of experimental NIDs;
   they those names are intended for use within internal no longer members or limited experimental
   contexts.  However, as described below in Section 4.1, these are
   designated by a specific form customers of the NID
      that organization.  With regard to allow differentiation
   (without preexisting knowledge URN resolution, this does not
      mean that there needs to be resolution of details) from such names, only that
      the other URN
   Namespace types.

3.2. names will not resolve to false or stale information.

5.2.  Informal Namespaces

   These

   Informal namespaces are fully fledged full-fledged URN Namespaces, namespaces, with all the
   rights and
   requirements responsibilities 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
   (described below) namespaces
   differ from formal namespaces in the NID assignment. process for assigning a NID:
   IANA will assign to
   registered Informal Namespaces a simply structured, alphanumeric,
   ordinal an alphanumeric NID (following a pattern defined in Section 4.2 below), (e.g., "urn-7") to informal
   namespaces, per the process outlined in under Section 4.

3.3.  Formal Namespaces

   A Formal 7.

6.  Defining a URN Namespace may be requested, and IETF review sought, in cases
   where

   A URN namespace is defined by the publication following factors:

   o  The syntax of URNs assigned within the NID proposal and namespace, in conformance
      with the underlying fundamental URN syntax [I-D.saintandre-urnbis-2141bis].
   o  The process for assigning URNs within the namespace.
   o  Optionally, the process for resolving URNs issued within the
      namepace.

   Processes for resolution of URNs assigned within a namespace will (if any)
   are out of scope for this document.  The following sections provide benefit to some subset
   guidelines for (1) defining the syntax of users on URNs within a namespace and
   (2) specifying how URNs will be assigned within a namespace.

6.1.  Formal Namespaces

   Formal NIDs are assigned as a result of IETF Consensus as defined in
   the
   Internet.  That is, "IANA Considerations" document [RFC5226].  Thus an application
   for a formal NID proposal, if accepted, must is made by publishing an RFC through normal IETF
   processes.  The RFC need not 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 material.  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 however 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 with it
   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 benefit for the Internet community from
   formally establishing the proposed URN Namespace -- see Sections
   4.4.1 and 4.4.2 below.

   Additionally, since the goal of URNs is to provide persistent
   identification, careful consideration must be given to the longevity
   and maintainability of the URN Namespace.  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:

   -  the organization maintaining the URN Namespace should credibly
      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;

   -  the organization(s) assigning URNs within the URN Namespace should
      demonstrate ability and competency in name assignment; this should
      improve the likelihood of persistence (e.g., to minimize the
      likelihood of conflicts);

   -  the organization(s) assigning URNs within the URN Namespace need
      to be committed to honor the scope, rules, and regulations
      outlined in its registration document and the documents defining
      the underlying namespace and covering its identifier assignment
      and maintenance procedures (if any), and the organization
      maintaining the URN Namespace needs to have procedures in force
      that aim at ensuring this adherance at a very high confidence
      level; and

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

   If the underlying namespace is based on an established standard, the
   standards body or the organization(s) in charge with the maintenance
   of the namespace should be involved in the process, either by
   performing the registration on their own, or by supporting the action
   of the registrant and asserting support of the registration document.

   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 (for instance 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 by IANA or
   may request a particular identifier.

   The IANA Considerations Guidelines document (BCP 26 [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 at [IANA-URN].  The registry 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 between the
   Namespace types defined in Section 3.  The process generally makes
   use of the urn-nid@ietf.org discussion list, where, under the
   auspices of the designated expert(s), volunteering experts and other
   interested parties review URN Namespace proposals.

   NOTE:  The nominal review period on that list (repeatedly quoted
      below) is specified in this document as four weeks.  This is an
      upper limit intended to grant the experts following the list
      sufficient headroom and flexibility.  The designated expert(s) may
      always come to a conclusion earlier, based on personal judgement,
      observation of feedback on the list, and the precedents of a
      submission.

   Registrations may be revised by updating the Namespace definition
   document using the same process as used for initial registrations,
   including the circulation of the draft form of the revised Namespace
   definition document on the urn-nid discussion list.

4.1.  Experimental Namespaces: No Registration

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

      X-<nid>

   where <nid> is a string of up to 30 characters, 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.

   NOTE:  The above form is no more considered MANDATORY, in order to
      accommodate experience and demonstrated evidence that, under
      specific circumstances, experimental prototype systems have to
      create and assign identifiers that the interested community
      perceives are infeasible to be changed once the Namespace gets
      formally registered.  However, it is still RECOMMENDED to prefix
      eventually targeted NIDs by "X-" during experiments and tests.

   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 (ordinal) 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 four-week discussion period for clarifying
   the expression of the registration information and suggestions for
   technical improvements to the Namespace proposal.

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

4.3.  Formal Namespaces

   Formal NIDs are assigned via IETF Review and Expert Review, as
   defined in BCP 26 [RFC5226].

   "IETF Review" 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.  The actual choice should be properly considered by
   applicants, but 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 RFC.

   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 designated expert(s) for
   URN Namespace registrations are nominated by the IESG, and their role
   adheres to the guidelines in BCP 26, unless specified otherwise
   below.  The template defined in Appendix A SHOULD be included as part
   of an RFC-to-be defining some other aspect(s) of the Namespace, but
   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).  The applicant has to allow for a 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).  Multiple iterations can be
   performed, before the proposal is accepted and the document can be
   forwarded to the IESG for review at large. the

   Working groups generally SHOULD seek early expert review for a
   Namespace definition document, and individual applicants are also
   advised to seek expert comments early enough.  The aforementioned
   list can be contacted for informal advice at any stage.  The document
   writeup needed for submitting a working group document to the IESG
   requires that all applicable Expert Review processes have been
   followed; this applies to the process described here.

   NIDs for Formal URN Namespaces MUST NOT have the forms indicated in
   the preceding two sections for the other two Namespace types.  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);

      -  not be equal to or start with "example" (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 future 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; To allow neutral example URNs in code and documentation,
      NID strings starting with "example" are set aside for use in
      documentation; IANA has permanently reserved these string to
      prohibit assignment.

   Applicants, in concert with the designated expert(s), should ensure
   that the sought NID strings are "proper" for the designated purpose,
   according to common sense (and applicable legal rules).

4.4.  Registration Documents

   The following subsections describe essential, MANDATORY parts of URN
   Namespace registration documents (beyond the registration template
   specified in Appendix A), 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 section with
   "Namespace Considerations" that outlines the perceived need for a new
   namespace (i.e., where existing namespaces fall short of the
   proposer's requirements).  Part of the expected elaborations need to
   be the arguments why other identifier systems, in particular a
   specific/new URI Scheme would not be suitable for the intended
   purpose.

   The basis for the expected reasoning can be laid by collecting and
   analyzing the requirements for the new namespace or, if an existing
   identifier system shall be incorporated into the URN system, from
   studying applicable stable (and preferably readily available)
   documents related to that identifier system that can be quoted.
   Particular insight to properly decide whether a new namespace is
   needed can be gained from preparing the explanations to be filled
   into clauses of the Registration template in Appendix A related to:

      -  kind of resources to be named;

      -  URN assignment procedures;

      -  URN resolution/delegation;

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

   If the need for a new namespace can be demonstrated, it needs to be
   checked whether the requirements and properties of the desired
   identifer system is properly matched to the basic assumptions and
   requirements for URNs -- cf. the Introduction of RFC 2141bis
   [I-D.ietf-urnbis-rfc2141bis-urn].  If that is not obvious, it needs
   to be explained in detail in the Namespace Considerations.

   See the trailing NOTE of the next Section for exceptional conditions
   that might allow to waive the need for presenting the above-described
   rationale in a standalone section of a particular Namespace
   definition document.

4.4.2.  Community Considerations in Registration Documents

   The Namespace definition document MUST also include a section with
   "Community Considerations" 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.

   Again, insight into arguments needed here might be possible to be
   gained by preparing the material to be filled into clauses of the
   Registration template in Appendix A related to:

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

   NOTE:  It is acknowledged that occasionally the Namespace
      Considerations and Community Considerations are closely
      intertwined; e.g., this has has been observed in the context of
      legacy identifier systems to be embedded into a URN Namespace.
      If such circumstances can be demonstrated, the Expert Review
      process can waive the requirement to present the two independent
      sections of a Namespace defintition document described in this and
      the preceding Section and concede to the applicant(s) to combine
      the content required for those two mandatory sections into a
      single "Namespace and Community Considerations" section.

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
   [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 template that is to be
   entered into the IANA registry of either Informal or Formal URN
   Namespaces.

   The completed Namespace registration template included in (or
   referred by) the IANA Considerations section in the published form of
   Registration documents will provide the particular, unique NID string
   that has been assigned, in case of formal Namespaces, by the
   Standards/Protocol Action of the IESG that approved the publication
   of the registration document as an RFC, or, in case of informal
   Namespaces, by the IANA after successful Expert Review.  As specified
   above in Section 4.3, draft registration documents for formal
   Namespaces usually carry the NID suggested by the registrant (subject
   to the expert review process); otherwise the NID will be assigned by
   the IANA.  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.  Additional
   syntactical constraints for NIDs are specified (per Namespace type)
   in Sections 4.2 and 4.3 above.

   Applicants and the designated expert(s) have to ensure that the
   sought NID strings are suitable and proper for the designated purpose
   and not misleading, according to common sense and applicable legal
   rules.  The IETF Review process gives interested parties the
   opportunity to rise concerns if they want to challenge proposed
   strings; the final approval decision still remains with the IESG.

   To avoid clerical accidents, the IANA Considerations Section in
   Namespace registration documents should clearly spell out the
   implications of the registration on the URN Query Parameters
   registries defined in RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn],
   if any.  Namespace registration documents have to specify the use or
   non-use of query instructions (by registered keyword) by the
   resolvers related to the respective namespace.  Additionally, they
   can optionally define new query keywords (of specific scope) for that
   Namespace or an entire group of Namespaces.

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 described in Section 4 of this RFC.

   IANA is asked to update the applicable policy for the registry of
   Formal URN Namespaces in the list of protocol parameter registries at
   http://www.iana.org/protocols/, replacing "IETF Consensus Action" by
   "IETF Review after expert review on the urn-nid discussion list
   (designated expert: ...)".

   In both sub-registries of [IANA-URN] (for Formal and Informal
   Namespaces), the registry column headings "URN Namespaces" should be
   changed to "Namespace ID", and "Value" to "Ordinal"; preferably these
   columns should be swapped in both sub-registries.
   [[ DISCUSS: Do we actually need these numerical columns at all? ]]

   IANA is asked to add to both sub-registries of [IANA-URN] a new third
   column entitled "Kind of named resources"; entries into this column
   shall be captured from the respective clause of received registration
   templates conforming to Appendix A.  For legacy entries, the original
   registrants are encouraged to provide proper short descriptions to
   IANA.
   [[ DISCUSS: Shall *we* provide sensical values for legacy entries
   and/or actively poll the Namespace owners instead? ]]

   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 of this document outlines the general procedures.  Sections
   4.2 and 4.3 above describe the syntax rules for NIDs to which the
   registry needs to obey.

   As pointed out in Section 4.3 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.  All strings starting
   with "example" are permanently reserved for use in code and
   documentation, and hence MUST NOT be assigned as an NID.

   In conformance with BCP 100 [RFC4020], 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.

   Once a Namespace registration template has been accepted for IANA
   processing, the IANA is expected to also update the "Supported by"
   lists in the registry specified by Section 9.2.1 of RFC 2141bis
   [I-D.ietf-urnbis-rfc2141bis-urn], based on the information supplied
   in the "Usage of query instructions" clause of the registration
   template.

7.  Acknowledgements

   This document is heavily based on RFC 3406 (and thereby its
   predecessor, RFC 2611), authored by Leslie Daigle, Dirk-Willem van
   Gulik, Renato Ianella, and Patrik Faltstrom, whose work is 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 (in alphabetical order)
   Leslie Daigle Juha Hakala, Subramanian Moonesamy.  Peter Saint-Andre,
   Lars Svensson, 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-03 (work in progress),
              October 2012.

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

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

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

   [RFC3339]  Klyne, G., Ed. and C. Newman, "Date and Time on the
              Internet: Timestamps", RFC 3339, July 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.

   [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.  It is provided in two versions; the
   annotated template with comments explaining what should go into the
   filled-out template is shown in Appendix A.1 and the plain template
   that can be used as a starting point for filling in the required
   information via plaintext editing is shown in Appendix A.2.
   To further the application of the template, both forms will be made
   available in xml2rfc form on the IETF Tools and/or IANA web site [[
   to be decided ]].
   In case of (unintended) deviations, Appendix A.1 takes precedence
   over Appendix A.2.

   Apart from providing a mechanism for disclosing the structure of the
   URN Namespace, this information is designed to be useful for

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

A.1.  Annotated URN Namespace Definition Template

   Information in the template is as follows (text in curly braces
   describes the expected content 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. }

   Kind of named resources:

      { Short description of what resources are named under this NID. }

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

   Declaration of syntactic structure of NSS part:

      {
      This clause 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 clauses.  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 clause 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:

      {
      This clause should outline any special considerations required 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 clause 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:

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

      However, namespaces that seek to provide higher-level lexical
      equivalence rules should preferably make use of established and
      standardized normalization procedures (like the methods leading to
      the various Unicode Normalization Forms, which would have to be
      applied before UTF-8 encoding) and not invent their own "magic";
      in practice, the utility of such things is likely to be limited
      since test of lexical equivalence is a typical client-side pre-
      screening operation performed by applications that try to remain
      as general as possible and typically will not have built-in, NID-
      specific knowledge -- ultimately, functional (or semantical)
      equivalence of URNs can only be decided in the NID-specific
      assignment/resolution systems, and their internal rules can be
      handled much more flexibly than more complicated, nailed-down
      lexical equivalence rules that are unlikely to be implemented at
      large.
      }

   Usage of query instructions:

      {
      Either say "not applicable" or describe the query instructions
      (keywords and associated values) supported by the resolvers for
      this Namespace (cf. Sections 2.5 and 9.2 of RFC 2141bis).
      Is the "s" keyword supported to select component resources?
      If yes: Which registered services can be selected with it?  What
      is the default/fallback service if "s=" is not given or if the
      value specified for it is unknown/unsupported?
      For which services is the "c" keyword supported (if any)?
      If affirmative, specify the values that can be used with it and
      the behavior if an unrecognized / inapplicable value is used.
      }

   Usage of fragment part:

      {
      Either say "not applicable" if <fragment> parts cannot sensically
      be used with URI references to URNs of this NID,
      or specify (by URN service supported) which media types that
      support fragment identifiers will be returned by the resolvers for
      this Namespace, and the <fragment> designators that will be
      applicable.  (Cf. Section 2.4 of RFC 2141bis.)
      }

   Identifier uniqueness considerations:

      {
      This clause should address the requirement that URN identifiers be
      assigned uniquely -- they are assigned standards track (indeed, to at date most one resource,
      and are not reassigned.

      (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
   RFCs registering URN namespaces have been informational), but it 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 clause 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 subject to authorities recognized by IESG review and acceptance pursuant to the guidelines
   written here (as well as standard RFC publication guidelines).

6.1.1.  Syntax

   A formal namespace registration requests a particular organization (e.g., the Digital Object Identifier
         Foundation controls NID, subject to
   the DOI assignment space and its
         delegation);
      -  assignment following constraints:

   o  It MUST NOT be an already-registered NID.
   o  It MUST NOT start with "urn-" (which is completely closed (e.g., for a private
         organization).
      }

   Process reserved for identifier resolution:

      {
      Which URN resolution services will informal
      namespaces).
   o  It MUST be supported?
      What more than 2 letters long.
   o  It MUST NOT start with "XY-", where XY is the default service provided by the resolvers for this
      Namespace?
      (The "Usage any combination of query instructions:" clause above only reports
      which services can be selected two
      ASCII letters.

   All two-letter combinations, and all two-letter combinations followed
   by the "s" query instruction, if
      any.)
      }
      {
      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 any sequence of the RDS.  What this clause should
      outline is the requirements valid NID characters, are reserved for becoming a recognized resolver
   potential use as countrycode-based NIDs for eventual national
   registrations 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 URN namespaces.  The definition and scoping of rules
   for
         updating an appropriate RDS;
      -  resolution is controlled by entities to which assignment has
         been delegated.
      }

   Validation mechanism:

      {
      Apart from attempting resolution allocation of a URN, a URN Namespace may
      provide mechanisms responsibility for "validating" a URN -- i.e., determining
      whether a given string such countrycode-based
   namespaces is currently beyond the scope of this document.

6.1.2.  Specification

   The specification defining a validly-assigned URN.  There
      are 2 issues here: 1) users should not "guess" URNs in formal namespace MUST include a
      Namespace; 2) when the URN Namespace is based on an existing
      identifier system, it may not be
   completed namespace definition template (see Section 8).

   The specification also MUST include the case that all following sections.

   The "Namespace Considerations" section outlines the perceived need
   for a new namespace (i.e., where existing
      identifiers are namespaces fall short of
   the proposer's requirements).  Potential considerations include:

   o  Procedures for assigning URNs within this namespace
   o  Processes for resolving URNs assigned on Day 0. within this namespace, if
      any
   o  The reasonable expectation type of resources to be identified
   o  The type of services to be supported

   It is expected that more than one namespace may serve the resource associated with each resulting URN is somehow
      related to same
   "functional" purpose; the thing identified by intent of 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 "Namespace Considerations"
   section is not clear that all telephone numbers would
      immediately become "valid" URNs, that could be resolved using
      whatever mechanisms are described as part to provide a record of the Namespace
      registration.

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

   Scope:

      {
      This clause should outline proposer's "due diligence" in
   exploring existing possibilities, for the scope IESG's consideration.

   The "Community Considerations" section explains how the intended
   community will 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:

   o  Open assignment and use of the identifiers
      in this namespace, i.e. within the precise kind namespace
   o  Open operation of resources to which resolution servers for the
      URNs are assigned.  Apart from considerations namespace (server)
   o  Creation of private vs.
      public namespaces, this clause is critical in evaluating software that can meaningfully resolve and access
      services for 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 (client)

   The "IANA Considerations" section indicating that the other hand, at document
   includes a national level, it URN NID registration that is
      reasonable to propose a URN Namespace for "this nation's social
      security numbers".
      }

A.2.  Plain URN Namespace Definition Template (Informative)

   Namespace ID:  ...

   Kind of named resources:  ...

   Registration Information:

      -  version number:  _
      -  date:  yyyy-mm-dd

   Declared registrant of be entered into the Namespace:

      -  Registering organization:
           Name: ...
           Address: ...
      -  Designated contact person:
           Name: ...
         { Address: ... }

   Declaration of syntactic structure IANA
   registry of NSS part:

      ...

   Relevant ancillary documentation:

      ...

   Conformance with URN Syntax:

      ...

   Rules for Lexical Equivalence of NSS part:

      ...

   Identifier uniqueness considerations:

      ...

   .. [[ to be completed in next draft rev if this idea is accepted ]]

      ...

Appendix B.  Summary of Registration Steps (Informative)

   The key steps for registration of NIDs.

6.2.  Informal or Formal Namespaces
   typically play out as follows:

   A)

   Informal NID:

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

      2.  Communicate the registration template to urn-nid@ietf.org for
          technical review -- as an email with IANA.

   The namespace identifier assigned by IANA is a pointer to the
          submitted I-D or inline text containing the template.

      3.  Update number sequence in the registration template (and/or document)
   format:

       "urn-" <number>

   where <number> is chosen by the IANA on a First Come First Served
   basis as
          necessary from comments, and repeat steps 2 specified in the "IANA Considerations" deocument [RFC5226].

   The only restrictions on <number> are (1) that it consist strictly of
   digits and 3 as
          necessary.

      4.  Once comments have been addressed (and (2) that it not cause the review period has
          expired), send a request NID to IANA with exceed the revised registration
          template.

   B) length
   limitations defined in the URN syntax specification
   [I-D.saintandre-urnbis-2141bis].

7.  Registering a URN Namespace

7.1.  Formal NID: Namespaces

   The key steps for registration of a formal namespace are:

   1.  Write an Internet-Draft describing the namespace and include that includes all of the registration template, duly completed.  Be sure to include
          "Namespace Considerations" and "Community Considerations"
          sections (or a combined section for these), "Security
          Considerations" and "IANA Considerations" sections, as information
       described in under Section 4.4. FIXME.
   2.  Submit  Send the Internet-Draft, and send a pointer completed namespace definition template to the I-D
          (perhaps using a copy of the I-D announcement) to
       urn-nid@ietf.org in order to solicit discussion list for technical review.
   3.  Update the Internet-Draft as necessary from comments, needed to address feedback, and
       repeat steps 2 and 3 as needed.
   4.  If  Based on comments received, update the Internet-Draft is the product of and repeat
       steps 2 and 3 as necessary.
   5.  Send a working group in the
          IETF, follow the usual WG process request to forward the document IESG to publish the IESG for publication I-D 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 (published 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
   6.  If the IESG approves the document for publication as an RFC, send
       a request to IANA
          processing of the document will follow the regular work-flow
          between the RFC Editor and IANA.  This way, to register the NID requested NID.

   A registration will can be made public revised by IANA when the RFC is
          published.

Appendix C.  Changes from RFC 3406 (Informative)

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. in next iteration of this memo. ]]

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

   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 updating the utility RFC through normal IETF
   processes [RFC2606].  The authors of
      Experimental the revised document need to
   follow the same steps outlined above for new registrations.

7.2.  Informal Namespaces and raises question

   The key steps for registration 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 an informal namespace are:

   1.  Complete the namespace definition template (see Section 4.2 ff: changed "home" 8).  This
       can be done as part of URN-NID registration an Internet-Draft.
   2.  Send the completed template to the urn-nid@ietf.org discussion
       list (it already had for technical review.
   3.  Based on comments received, update the template and repeat steps
       2 and 3 as necessary.
   4.  Once comments have been moved to addressed and the IETF Secretariat servers);

   o  Section 4.2: added Note review period has
       expired, send a registration request to challenge IANA (via the 2-week review period; in
      current practice, that is almost always exceeded,
       iana@iana.org email address) with the final template.

   Informal namespaces can also be revised by updating the template and some regard
   processing it as too short;

   o  Section 4.3: largely clarified procedures as they happen in
      practice; adapted language outlined above for conformance with RFC 5226; use new
      home registrations.

8.  URN Namespace Definition Template

   Definition of URN-NID (as mentioned above); a URN namespace is accomplished by completing 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
   following template.  Apart from providing a mechanism for Informal Namespaces as well, as far as practical;
      replaced "RFC" by "Registration Document"; Section 4.4 defining
   the structure of URNs assigned within the namespace, this information
   is
      subdivided for all mandatory sections;

   o  Section 4.4.1: made requirements a "MUST"; designed to be useful for:

   o  Sections 4.4.1 and 4.4.2: added common Note that challenges the
      need  entities seeking to split Namespace and Community Considerations, based on
      observed problems have a URN assigned in practice a namespace (if
      applicable)
   o  entities seeking to separate provide URN resolvers for a namespace (if
      applicable)

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

   As described under Section 7.1, applications for formal URN
   namespaces MUST also document "Namespace Considerations", "Community
   Considerations" and pointing "IANA Considerations".

   The information to overlap with clauses be provided 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 as follows:

     Namespace ID:

        Requested of Security Considerations
      section; advice IANA (formal) or assigned by IANA (informal).

     Registration Information:

        This is information to focus on namespace-specific considerations
      and refer identify the particular version of
        registration information:

        -  registration version number: starting with 1,
           incrementing by 1 with each new version
        -  registration date: date submitted to the SecCons in IANA, using the "generic" RFCs for
           format YYYY-MM-DD

     Declared registrant of the general
      issues;

   o  Section 4.4.4: amended discussion namespace:
        This includes:
           Registering organization
              Name
              Address
           Designated contact person
              Name
              Coordinates (at least one of IANA Considerations section; email address, phone
                           number, postal address)

     Declaration of syntactic structure:

        This section ought to outline any structural features of
        identifiers in this tries namespace.  At the very least, this
        description may be used to reflect standing practice and codifies that Formal
      NIDs introduce terminology used in
        other sections.  This structure may also be used for
        determining realistic caching/shortcuts approaches;
        suitable caveats ought to be provided.  If there are generally proposed by any
        specific character encoding rules (e.g., which character
        ought to always be used for single-quotes), these ought
        to be listed here.

        Answers might include, but are not limited to:

        -  the registrant; added Note that
      "urn" structure is permanently reserved and MUST NOT be assigned as opaque (no exposition)
        -  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 regular expression for parsing the identifier into
           components, including naming authorities

     Relevant ancillary documentation:

        This section ought to list any RFCs, standards, or other
        published documentation that defines or explains all or
        part of the role of this document, including a sketch namespace structure.

        Answers might include, but are not limited to:

        -  RFCs outlining syntax of the history;
      added teat that tries to precisely describe what is expected from
      IANA on approval namespace
        -  Other of this draft; added text on procedures and
      suggest a provisional assignment practice upon "thumbs-up" the defining community's (e.g., ISO) documents
           outlining syntax of the
      IANA Expert to protect prospective registrants from collateral
      damage on NID precedence identifiers 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 namespace
        -  Explanatory 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 introducing the Template: hint and commentary now all enclosed in
      curly braces, with not that these parts shall be removed when
      filling in namespace

     Identifier uniqueness considerations:

        This section ought to address the tempalte; indicate requirement that Formal NIDs URNs are normally
      proposed by registrant; changed date/time ref. from ISO 8601 to
      RFC 3339; use inherited term "percent-encoding";

   o  Appendix A
        assigned uniquely -- structure: moved formal clauses on Conformance with
      URN Syntax and Rules for Lexical Equivalence to vicinity of
      namespace specific syntax clause, i.e., they are assigned to which these at most one
        resource, and are closely
      related;

   o  Appendix A -- changes not reassigned.

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

        Possible answers include, but are not limited to:

        -  exposition of syntactic the structure of the identifiers, and Rules
           partitioning of the space of identifiers amongst assignment
           authorities which are individually responsible for Lexical Equivalence clauses now
      tentatively have been restricted to
           respecting uniqueness rules
        -  identifiers are assigned sequentially
        -  information is withheld; the NSS part only; this change namespace is described opaque

     Identifier persistence considerations:

        Although non-reassignment of URN identifiers ensures that a URN
        will persist in NOTEs and motivated by identifying a particular resource even after
        the observation "lifetime of repeated
      confusion in past and present registration documents, which
      hopefully can the resource", some consideration ought to be avoided (and
        given to the job persistence of the Expert and reviewers
      made easier) by leaving discussion usability of the invariate parts that
      cannot be re-specified there at the single place where they belong
      to: the NID URN.  This is fully specified
        particularly important in the initial clause, rules for
      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 case of
      scope URN namespaces providing
        global resolution.

        Possible answers include, but are not limited to:

        -  quality 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 service considerations

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

C.3.  Changes from URNbis WG I-D -00 identifier assignment:

        This section ought to -01

   Usage of terminology strenghtened.

   Clarified role and usage of Experimental Namespaces.

   Clarified NID strings for Formal Namespaces.

   Added hint that recommends Std. Track RFCs for NID applications based
   on established standard namespaces, and Informational detail the mechanisms and/or authorities
        for others.

   Changed standard review period from 2 assigning URNs to 4 weeks (pending
   discussion).

   Resolved with IANA: simple, traditional and generic URL used by IANA
   for the URN Namespace registry.  (Needed resources.  It ought to be re-opened in -02!)

   Numerous editorial enhancements and fixes.

C.4.  Changes from URNbis WG I-D -01 make clear whether
        assignment is completely open, or if limited, how to -02

   General text edits based on evaluation become an
        assigner of meeting and on-list
   comments.

   Updated and tightened 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 organizatorial requirements Digital Object Identifier
           Foundation controls the DOI assignment space and its
           delegation)
        -  assignment is completely closed (e.g., for Formal
   Namespace requests.

   Restored additional IANA Considerations -- due a private
           organization)

     Process for identifier resolution:

        If a namespace is intended to observed defects.

   Reserved NID strings "example.*" be accessible for documentation (as suggested by
   Larry Masinter, Peter Saint-Andre, and Julian Reschke).

   Added text on possible "higher level" methods global
        resolution, it needs to establish lexical
   equivalence of URNs, with the caveats that be registered in an RDS (Resolution
        Discovery System, see RFC 2276) such things are rather
   unlikely as DDDS.  Resolution
        then proceeds according to get traction in general-purpose client software.

   Removed historical Appendix B.1 (Example Template).

   Various editorial enhancements and fixes.

   Updated standard URI resolution processes,
        and expanded "Issues" Appendix (below) in preparation of
   usage the mechanisms of the IETF Issue Tracker.

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

   Due RDS.  What this section ought to
        outline is the scattered discussion requirements for becoming a recognized resolver
        of URNs in this namespace (and being so- listed in the previous draft version, RDS
        registry).

        Answers may include, but are not limited to:

        -  the
   items below namespace is not only list effected changes but also give rationale
   for where suggested changes have listed with an RDS; therefore this
           section is not been applied.

   Document title shortened to better reflect entire purpose of
   document.

   Abstract: revised and shortened (comments from SM).

   Introduction:
   Rephrased 1st para to put emphasis on name binding property (derived
   from list discussion on related topic, Keith Moore et al.).
   Amended / modified text applicable
        -  resolution mirroring is completely open, with a mechanism
           for updating an appropriate RDS
        -  resolution is controlled by entities to better reflect which assignment
           has been delegated

     Rules for Lexical Equivalence:

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

        Some examples include:

        -  equivalence between hyphenated and to accommodate non-hyphenated groupings
           in the evolution 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 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
        best practice for handling equivalences between characters;
        they are statements limited to maintain the
   assumption, not reflecting the 2nd assumption itself.
   Text reworked based on comments (SM, PSA, et al.).
   The single paragraph namespace's
        own rules.

     Conformance 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 URN Syntax:

        This section ought to
   capture important motivations outline any special considerations
        required for conforming with the document revision effort;
   therefore, it URN syntax.  This is kept
        particularly applicable in the draft.
   The pargraph describing the purpose case of the document has been
   rephrased.  It isn't barely about an IANA procedure, it is also about
   what prospective registrants legacy naming
        systems that are well advised to consider before
   deciding on a new Namespace and the processes they have to implement,
   and finally capturing the results used in a URN Namespace registration
   document.

   Section 2:
   Amended by text describing the 3 methods available to Namespace
   designers / stakeholdes to make component resources context of structured
   resources identifiable/accessible.
   Some existing text reworded based on comments (SM et al.).
   It has been argued that text on URN Namespaces URNs.

        For example, if a namespace is used in s2 would better be
   placed into the rfc2141bis document, but on the contexts other hand, than URNs,
        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 may make use 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 characters that are reserved in RFC 3406; the text from there has
   been updated according to our chartered, to update for RFC 5226. URN
        syntax.

        This matter needs section ought to be taken into account by prospective Namespace
   owners, flag any such characters, and thus the text makes sense in this document.
   Reorganization of subsequent text made it logically outline
        necessary mappings to
   include into conform to URN syntax.  Normally, this
        will be handled by hex encoding the symbol.

        For example, see the section a high level description on SICIs in RFC 2288.

     Validation mechanism:

        Apart from attempting resolution of the
   urn-nid@ietf.org list.  The nominal review period is left a four
   weeks in this draft revision, but URN, a Note has been added to s4
   indicating that this is an upper limit to accommodate headroom,
   whereas the designated expert(s) URN namespace may always come to a conclusion
   earlier.
   Repeated references to IANA have been consolidated.
   The common shorthand designation "IANA experts"
        provide mechanisms for the designated
   expert(s) supporting IANA in the maintenance of the "validating" a URN NID registry -- i.e., determining
        whether a given string is now being avoided.

   s4.1: No technical changes.  The continued use of the "X-" prefix for
   Experimental Namespaces does currently a validly-assigned URN.
        There are two issues here: 1) users ought not violate RFC 6648 because this "guess" URNs in
        a namespace; 2) when the URN namespace is
   legacy practice, experimental NIDs are based on an existing
        identifier system, it may not being registered, and this
   memo again prohibits be the use of Experimental Namespaces in case that all the open
   Internet.

   s4.3:
   Text reorganized, incorporating material from s4.4.4 (see below).
   The text existing
        identifiers are assigned on Day 0.  The reasonable expectation
        is that the (modified) "IETF Review" policy has been upgraded
   from RFC 3406 (and thereby effectively shortened).  It serves to give
   concise information resource associated with each resulting URN is
        somehow related to the expected primary audience of thing identified by the document,
   applicants original
        identifier system, but those resources may not exist for Namespaces, which according to experience each
        original identifier.  For example, even if a URN namespace were
        defined based on telephone numbers, it is not clear that all
        telephone numbers would immediately become "valid" URNs, that
        could be resolved using whatever mechanisms are rather
   unlikely inclined described as
        part of the namespace registration.

        Validation mechanisms might be:

        -  a syntax grammar
        -  an on-line service
        -  an off-line service

     Scope:

        This section ought to read outline the full RFC 5226, but just need to know
   what is said in scope of the single sentence in use of the draft.  Further,
        identifiers in this
   sentence supplies the background information for the following
   sentences and thus improved the readability namespace.  Apart from considerations of
        private vs. public namespaces, this section is critical in
        evaluating 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 applicability of the registration
   template where working on the text to be supplied there will likely
   give insights to answer the basic questions a requested NID.  For example,
        a namespace claiming to be answered here.
   A NOTE now tentatively allows deal in "social security numbers"
        ought to include a combined Namespace and
   Community Considerations section into have a Namespace registration
   document, if the expert review admits it.

   s4.4.3: The first sentence lays the foundation for the subsequent
   sentences global scope and gives address all social security
        number structures (unlikely).  On the appropriate reference (to BCP 72); hence other hand, at a national
        level, it is regarded as non-disposable -- no change.
   Repeated negative experience has motivated the addition of reasonable to propose 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 namespace for "this
        nation's social security numbers".

9.  Security Considerations

   This document largely focuses on providing mechanisms for the IESG (document writeup requirement).

   s4, s4.4.4: Last paragraph ostensibly belonging to s4.4.4 moved to
   end
   declaration of s4, then adjusted to context.  (The RFC format doesn't allow
   to recognize the continuation public information.  Nominally, these declarations
   will be of a higher-level section after relatively low security profile, however there is always
   the
   inclusion of sub-sections.)

   s4.3, s4.4.4: The checklist of syntactical constraints for NIDs danger 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 "spoofing" and related text has been modified accordingly.

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

   IANA Cons. (s6): Added request providing mis-information.  Information
   in these declarations ought to be taken as advisory.

10.  IANA to clarify Considerations

   This document outlines the procedures processes for registering URN namespaces,
   and has implications for
   Formal NIDs in the list IANA in terms of ptorocol parameter registries.

   Updated and expanded Acknowledgements.

   References: RFC 3339 demoted to Informational; you don't need registries to read
   it be
   maintained.  In all cases, the IANA ought to insert assign the date into appropriate
   NID (informal or formal), as described above, once an IESG-designated
   expert has confirmed that the requisite 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 process steps
   have been completed.

11.  References

11.1.  Normative References

   [I-D.saintandre-urnbis-2141bis]
              Saint-Andre, P. and R. Moats, "Uniform Resource Name (URN)
              Syntax", draft-saintandre-urnbis-2141bis-00 (work in curly braces embedded
              progress), October 2012.

   [RFC2119]  Bradner, S., "Key words for use in the
   annotated registration template.  Use term "clause" throughout.
   Removed Notes from template that served RFCs to explain previous changes.
   Template now provided in both annotated Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5226]  Narten, T. 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 H. Alvestrand, "Guidelines for Purpose of Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

11.2.  Informative References

   [RFC2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
              Names", BCP 32, RFC 2606, June 1999.

   [RFC2611]  Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
              "URN Namespace
   (short description of named resources), applicability of <query> part Definition Mechanisms", BCP 33, RFC 2611,
              June 1999.

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

   [RFC6648]  Saint-Andre, P., Crocker, D., and applicability of
   <fragment> part. M. Nottingham,
              "Deprecating the "X-" Prefix and Similar Constructs in
              Application Protocols", BCP 178, RFC 6648, June 2012.

Appendix B: The A.  Changes from RFC 3406

   Although on the surface it might appear that this document organization is carried over
   significantly different from RFC 3406.
   Modified title [RFC3406], in general it only modifies
   the order of presentation, with the intent of App. B, declared making it Informative.

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

   Multiple editorial fixes easier for
   people to define and enhancements.

Author's Address

   Alfred Hoenes register URN namespaces.  However, the only
   major substantive change is removing the category of experimental
   namespaces, in accorance with [RFC6648].

Authors' Addresses

   Peter Saint-Andre (editor)
   TR-Sys
   Gerlinger Str. 12
   Ditzingen  D-71254
   Germany

   EMail: ah@TR-Sys.de
   Cisco Systems, Inc.
   1899 Wynkoop Street, Suite 600
   Denver, CO  80202
   USA

   Phone: +1-303-308-3282
   Email: psaintan@cisco.com

   Leslie Daigle

   Dirk-Willem van Gulik

   Renato Iannella

   Patrick Faltstrom