URNBIS                                                    P. Saint-Andre, Ed. Saint-Andre
Internet-Draft                                       Cisco Systems, Inc.
Obsoletes: 3406 (if approved)                                  L. Daigle                          November 13, 2013
Intended status: BCP                            Thinking Cat Enterprises
Expires: January 13, May 17, 2014                                   D. van Gulik
                                                              WebWeaving
                                                             R. Iannella
                                                       Semantic Identity
                                                            P. Faltstrom
                                                                  Netnod
                                                           July 12, 2013

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

Abstract

   This document supplements the Uniform Resource Name (URN) syntax
   specification by defining the concept of a URN namespace, as well as
   mechanisms for defining and registering such namespaces.  This
   document obsoletes RFC 3406.

Status of 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 January 13, May 17, 2014.

Copyright Notice

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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  What is a URN Namespace? . . . . . . . . . . . . . . . . . . .  4
   4.  URN Namespace Types  . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Formal Namespaces  . . . . . . . . . . . . . . . . . . . .  5
     4.2.  Informal Namespaces  . . . . . . . . . . . . . . . . . . .  6
   5.  Defining a URN Namespace . . . . . . . . . . . . . . . . . . .  6
     5.1.  Formal Namespaces  Purpose  . . . . . . . . . . . . . . . . . . . . . . . . .  7
       5.1.1.
     5.2.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . .  7
       5.1.2.  Specification
     5.3.  Assignment . . . . . . . . . . . . . . . . . . . . .  7
     5.2.  Informal Namespaces . . .  8
     5.4.  Security . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Registering a URN Namespace .  9
     5.5.  Resolution . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Registration Template  . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Formal Namespaces  Namespace ID . . . . . . . . . . . . . . . . . . . .  9 . . . 10
     6.2.  Informal Namespaces  Version  . . . . . . . . . . . . . . . . . . .  9
   7.  URN Namespace Definition Template . . . . . . 10
     6.3.  Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Security Considerations
     6.4.  Registrant . . . . . . . . . . . . . . . . . . . 15
   9.  IANA Considerations . . . . . 10
     6.5.  Purpose  . . . . . . . . . . . . . . . . 15
   10. References . . . . . . . . . 10
     6.6.  Syntax . . . . . . . . . . . . . . . . . 15
     10.1. Normative References . . . . . . . . . 10
     6.7.  Assignment . . . . . . . . . . 15
     10.2. Informative References . . . . . . . . . . . . . . 10
     6.8.  Resolution . . . . 16
   Appendix A.  Changes from RFC 3406 . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . 10
     6.9.  Documentation  . . . . . . . . . . . . . . . . . . . . 16

1.  Introduction

   A Uniform Resource Name (URN) [I-D.ietf-urnbis-rfc2141bis-urn] is a
   Uniform Resource Identifier (URI) [RFC3986] that is intended to serve
   as a persistent, location-independent resource identifier.  This
   document supplements the Uniform Resource Name (URN) syntax
   specification [I-D.ietf-urnbis-rfc2141bis-urn] by defining the
   following:

   o  The concept of . . 10
   7.  Registering a URN namespace.
   o  A mechanism for defining URN namespaces and associating each
      namespace with a public identifier (called a Namespace ID or
      "NID").
   o  Procedures for registering namespace identifiers with the Internet
      Assigned Numbers Authority (IANA).

   This document rests on two key assumptions:

   1.  Assignment of a URN is a managed process.

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

   2.  The space of URN namespaces is itself managed.

       A string in the namespace identifier slot of the URN syntax is
       not necessarily a valid URN namespace identifier, because in
       order to be valid a namespace needs to be defined and registered
       in accordance with the rules of this document.

   URN namespaces were originally defined in [RFC2611], which was
   obsoleted by [RFC3406].  Based on experience with defining and
   registering URN namespaces since that time, this document specifies
   URN namespaces with the smallest reasonable set of changes  . . . . . . . . . . . . . . . . . 11
     7.1.  Formal Namespaces  . . . . . . . . . . . . . . . . . . . . 11
     7.2.  Informal Namespaces  . . . . . . . . . . . . . . . . . . . 11
   8.  Guidelines for Designated Experts  . . . . . . . . . . . . . . 11
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     11.2. Informative References . . . . . . . . . . . . . . . . . . 12
   Appendix A.  Changes from
   [RFC3406].  This document obsoletes RFC 3406.

2.  Terminology

   Several important terms used in this document are defined in the URN
   syntax specification [I-D.ietf-urnbis-rfc2141bis-urn].

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

3.  What is a URN Namespace?

   For the purposes of URNs, a "namespace" is a collection of unique
   identifiers that are consistently assigned according to a common
   definition.

   The uniqueness constraint means that an identifier within the
   namespace is never assigned to more than one resource and never re-
   assigned to a different resource (however, a single resource can have
   more than one URN assigned to it for different purposes).

   The consistent assignment constraint means that an identifier within
   the namespace is assigned by an organization or in accordance with a
   process that is always followed (e.g., in the form of an algorithm).

   The common definition constraint means that both the syntax for
   identifiers within the namespace and the process for assigning such
   identifiers are clearly defined in a specification. 3406 . . . . . . . . . . . . . . . . 13
   Appendix B.  Contributors  . . . . . . . . . . . . . . . . . . . . 13
   Appendix C.  Acknowledgements  . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.  Introduction

   A URN namespace Uniform Resource Name (URN) [I-D.ietf-urnbis-rfc2141bis-urn] is identified by a particular designator (which
   syntactically follows the 'urn' scheme name) in order to:

   o  Ensure the global uniqueness of URNs.
   o  Optionally provide a cue regarding the structure of URNs assigned
      within a namespace.

   With regard to global uniqueness, using different designators for
   different collections of identifiers ensures
   Uniform Resource Identifier (URI) [RFC3986] that no two URNs will be
   the same for different resources (since each collection is required intended to uniquely assign each identifier).  For instance, some identifier
   systems use strings of numbers serve
   as identifiers (e.g., ISBN, ISSN,
   phone numbers).  It is conceivable that some numbers might be valid
   identifiers in two different established identifier systems, where
   the namespace identifier differentiates between the resulting URNs.

   With regard to 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 identifiers, 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, developers of particular application protocols, etc.);
   therefore these issues are beyond persistent, location-independent resource identifier.  This
   document supplements the scope of URN Uniform Resource Name (URN) syntax and the
   rules regarding URN namespaces in general.

   URN namespaces inherit certain rights and responsibilities,
   including:
   specification [I-D.ietf-urnbis-rfc2141bis-urn] by defining:

   o  They uphold the general principles  The concept of a well-managed URN namespace
      by providing persistent identification of resources and unique
      assignment of identifier strings. namespace.

   o  They can be registered in global registration services.

4.  URN Namespace Types

   There are two types of URN namespace: formal and informal.  These are
   distinguished by the expected level of service, the information
   necessary to define the namespace, and the procedures  A mechanism for
   registration.  To date, the vast majority of the registered
   namespaces have been formal, so this document concentrates on formal
   namespaces.

   Note: [RFC3406] defined defining a third type of "experimental namespaces",
   denoted by prefixing the namespace identifier with the string "X-".
   Consistent with [RFC6648], this specification removes the
   experimental category.

4.1.  Formal Namespaces

   A formal namespace can be requested, and IETF review sought, in cases
   where the publication of the NID proposal and the underlying URN namespace will provide benefit to some subset of users on the
   Internet.  That is, a formal NID proposal, if accepted, needs to be
   functional on and associating it with the global Internet, not limited to users in
   communities or networks not connected to the Internet.  For example,
   consider a NID that is meant for naming of physics research; if that
   NID request effectively forced someone to use
      public identifier (called a proprietary network Namespace ID or service that was not at all open to the general Internet user,
   then it would make a poor request "NID").

   o  Procedures for a formal NID.  The intent is
   that, while registering NIDs with the community of those who might actively use Internet Assigned Numbers
      Authority (IANA).

   Syntactically, the names
   assigned within that NID follows the 'urn' scheme name.  For instance,
   a URN in the 'example' namespace [RFC6963] might be small (but no less important), of the
   potential use form
   "urn:example:foo".

   This document rests on two key assumptions:

   1.  Assignment of names within that NID a URN is open a managed process.

       A string that conforms to any user on the
   Internet.

   It URN syntax is expected that formal NIDs might not necessarily a
       valid URN, because a URN needs to be applied assigned according to the
       rules of a particular namespace (in terms of syntax, semantics,
       and process).

   2.  The space of URN namespaces where
   some aspects are is itself managed.

       A string in the namespace identifier slot of the URN syntax is
       not fully open.  For example, necessarily a valid URN namespace might make
   use of identifier, because in
       order to be valid a fee-based, privately managed, or proprietary registry for
   assignment namespace needs to be defined and registered
       in accordance with the rules of URNs this document.

   URN namespaces were originally defined in [RFC2611], which was
   obsoleted by [RFC3406].  Based on experience with defining and
   registering URN namespaces since that time, this document specifies
   URN namespaces with the namespace.  However, it might still provide
   benefit to some Internet users if smallest reasonable set of changes from
   [RFC3406], while at the services associated have
   openly-published access protocols.

   In addition to same time simplifying the basic information specified registration
   process.  This document obsoletes RFC 3406.

2.  Terminology

   Several important terms used in this document are defined in the namespace
   definition template (see Section 7), a formal namespace request needs URN
   syntax specification [I-D.ietf-urnbis-rfc2141bis-urn].

   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 accompanied by documented considerations of the need for interpreted as described in
   [RFC2119].

3.  What is a new
   namespace and of the community benefit from formally establishing the
   proposed URN namespace.

   Additionally, since the goal of URNs Namespace?

   A URN namespace is to provide persistent
   identification, a formal namespace request needs to give some
   consideration as to the longevity and maintainability collection of the
   namespace.  Possible factors to consider with regard to an
   organization identifiers that will assign URNs within are (1) unique,
   (2) assigned in a namespace include the
   following:

   o  It ought to demonstrate stability consistent way, and the ability (3) assigned according to maintain the
      URN namespace for a long time; absent such evidence, it ought to
      be clear how
   common definition.

   1.  The "uniqueness" constraint means that an identifier within the
       namespace can remain viable if the organization
      can no longer maintain the namespace.
   o  It ought to demonstrate competency in name assignment.  This will
      improve the likelihood of persistence (e.g. to minimize the
      likelihood of conflicts).
   o  It ought to commit is never assigned to not re-assigning existing names more than one resource and never
       reassigned to
      allowing old names to continue to be valid, even if a different resource.

   2.  The "consistent assignment" constraint means that an identifier
       within the owners namespace is assigned by an organization or
      assignees of those names are no longer members minted in
       accordance with a process or customers of algorithm that organization.  With regard to URN resolution, this does not
      mean is always followed.

   3.  The "common definition" constraint means that there needs to be resolution of such names, only that
      the names will not resolve to false or stale information.

4.2.  Informal Namespaces

   Informal namespaces are full-fledged URN namespaces, with all clear
       definitions for the syntax of identifiers within the
   rights namespace
       and responsibilities associated thereto.  Informal namespaces
   differ from formal namespaces in the process for of assigning a NID:
   IANA will assign an alphanumeric NID (e.g., "urn-7") to informal
   namespaces, per the process outlined under Section 6.

5.  Defining a URN Namespace or minting them.

   A URN namespace is defined identified by a particular NID in order to ensure
   the following factors:

   o  The syntax global uniqueness of URNs assigned within the namespace, in conformance
      with and, optionally, to provide a cue
   regarding the fundamental URN syntax [I-D.ietf-urnbis-rfc2141bis-urn].
   o  The process for assigning structure of URNs assigned within the a namespace.
   o  Optionally, the process

   With regard to global uniqueness, using different NIDs for resolving different
   collections of identifiers ensures that no two URNs issued within will be the
      namepace.

   Processes same
   for resolution different resources, since each collection is required to
   uniquely assign each identifier.  However, a single resource can have
   more than one URN assigned to it for different purposes (e.g., some
   numbers might be valid identifiers in two different identifier
   systems, where the namespace identifier differentiates between the
   resulting URNs).

   With regard to the structure of URNs assigned within a namespace (if any)
   are out of scope for this document.  The following sections provide
   guidelines for (1) defining namespace, the syntax
   development of URNs within an identifier structure (and thereby a namespace and
   (2) specifying collection of
   identifiers) depends on the requirements of the community defining
   the identifiers, how URNs the identifiers will be assigned within a namespace.

5.1.  Formal Namespaces

   Formal NIDs and used, etc.
   These issues are assigned as a result beyond the scope of IETF Review as defined in URN syntax and the
   "IANA Considerations" document [RFC5226].  Thus an application general rules
   for URN namespaces, because they are specific to the community
   defining a
   formal NID is made by namespace (e.g., the bibliographic and publishing an RFC
   communities in the IETF stream, either as
   the product case of an IETF working group or as an individual submission
   sponsored by an Area Director.  The RFC need not be standards track
   (indeed, to date most RFCs registering URN namespaces have been
   informational), but it will be subject to IESG review the 'ISBN' and approval
   pursuant to 'ISSN' namespaces, or the guidelines provided here (as well as standard RFC
   publication guidelines).

5.1.1.  Syntax

   A formal namespace registration requests a particular NID, subject
   developers of extensions to the following constraints (above Extensible Messaging and beyond the syntax rules
   specified Presence
   Protocol in [I-D.ietf-urnbis-rfc2141bis-urn]):

   o  It MUST NOT be an already-registered NID.
   o  It MUST NOT start with "urn-" (which is reserved for informal
      namespaces).
   o  It MUST be more than two characters long.
   o  It MUST NOT start with "XY-", where "XY" is any combination the case of two
      ASCII letters.

   All two-letter combinations, the 'XMPP' namespace).

   URN namespaces inherit certain rights and all two-letter combinations followed responsibilities, e.g.:

   o  They uphold the general principles of a well-managed URN namespace
      by "-" providing persistent identification of resources and any sequence unique
      assignment of valid NID characters, identifier strings.
   o  They can be registered in global registration services.

4.  URN Namespace Types

   There are reserved for
   potential use as countrycode-based NIDs for eventual national
   registrations two types of URN namespaces.  The definition namespace: formal and scoping of rules
   for allocation informal.  These are
   distinguished by the expected level of responsibility service, the information
   needed to define the namespace, and the procedures for such countrycode-based
   namespaces is beyond registration.
   Because the scope majority of the namespaces registered so far have been
   formal, this document.

5.1.2.  Specification

   The specification defining a document concentrates on formal namespace MUST include namespaces.

   Note: [RFC3406] defined a
   completed namespace definition template (see Section 7).

   The specification also MUST include third type of "experimental namespaces",
   denoted by prefixing the following sections.

   First, namespace identifier with the "Namespace Considerations" section outlines string "X-".
   Consistent with [RFC6648], this specification removes the perceived
   need for a new
   experimental category.

4.1.  Formal Namespaces

   A formal namespace (e.g., by describing where existing
   namespaces fall short provides benefit to some subset of users on the proposer's requirements).  Potential
   considerations include:

   o  The type of resources
   Internet (i.e., not limited to be identified
   o  The type of services users in communities or networks not
   connected to the Internet).  For example, it would be supported
   o  Procedures for assigning URNs within this namespace
   o  Processes inappropriate
   for resolving URNs a NID to effectively force someone to use a proprietary network
   or service not open to the general Internet user.  The intent is
   that, while the community of those who might actively use the names
   assigned within this namespace, if
      any

   It is expected that more than one namespace NID might serve the same
   "functional" purpose; be small, the intent potential use of the "Namespace Considerations"
   section
   identifiers within that NID is open to provide any user on the Internet.
   Formal NIDs might be appropriate when some aspects are not fully
   open.  For example, a record namespace might make use of the proposer's "due diligence" in
   exploring existing possibilities, a fee-based,
   privately managed, or proprietary registry for assignment of URNs in
   the consideration by the namespace.  However, it might still benefit some Internet community, expert reviewers, users
   if the associated services have openly-published access protocols.

   An organization that will assign URNs within a formal namespace ought
   to meet the following criteria:

   o  Organizational stability and the IESG.

   Second, ability to maintain the "Community Considerations" section explains URN
      namespace for a long time; absent such evidence, it ought to be
      clear how the
   intended community will benefit by assignment of this namespace, as
   well as how a general Internet user namespace can remain viable if the organization can
      no longer maintain the namespace.
   o  Competency in name assignment.  This will be able to use improve the space if
   they care likelihood
      of persistence (e.g. to do so.  Potential considerations include:

   o  Methods and benefits for using minimize the assigned URNs likelihood of conflicts).

   o  Methods  Commitment to not reassigning existing names and benefits for resolving to allowing old
      names to continue to be valid, even if the assigned URNs (if any)
   o  The kinds of software applications that can use owners or resolve the
      assigned URNs (e.g., by differentiating among disparate
      namespaces, identifying resources in a persistent fashion, assignees of
      those names are no longer members or
      meaningfully resolving and accessing services associated with the
      namespace)

   Third, the "Security Considerations" section describes any potential
   security-related issues with customers of that
      organization.  With regard to assignment, use, and URN resolution [RFC2276], this does
      not mean that there needs to be resolution of identifiers within the namespace.  Examples of such
   issues include names, only
      that the consequences of producing names will not resolve to false negatives or stale information.

   A formal namespace establishes a particular NID, subject to the
   following constraints (above and
   false positives during comparison beyond the syntax rules specified in
   [I-D.ietf-urnbis-rfc2141bis-urn]):

   o  It MUST NOT be an already-registered NID.
   o  It MUST NOT start with "urn-" (which is reserved for lexical equivalence (see also
   [RFC6943]), leakage informal
      namespaces).
   o  It MUST be more than two characters long.
   o  It MUST NOT start with "XY-", where "XY" is any combination of private information when identifiers two
      ASCII letters.

   All two-letter combinations, and all two-letter combinations followed
   by "-" and any sequence of valid NID characters, are
   communicated on the public Internet, the reserved for
   potential use as countrycode-based NIDs for directory
   harvesting, and the issues discussed in [RFC3552].

   Fourth, the "IANA Considerations" section indicates that the document
   includes a eventual national
   registrations of URN NID registration that namespaces.  The definition and scoping of rules
   for allocation of responsibility for such countrycode-based
   namespaces is to be entered into beyond the IANA
   registry scope of URN NIDs.

5.2. this document.

4.2.  Informal Namespaces

   Informal namespaces are directly requested of IANA full-fledged URN namespaces, with all the
   associated rights and are assigned
   based on responsibilities.  Informal namespaces differ
   from formal namespaces in the process for assigning a policy of First Come First Served [RFC5226].

   The namespace identifier assigned by NID: IANA has will
   assign an alphanumeric NID (e.g., "urn-7") to informal namespaces,
   with the following syntax:

       "urn-" <number>

   The <number> is chosen by IANA.  The only restrictions on <number> are that it (1) consist strictly of
   ASCII digits and (2) not cause the NID to exceed the length
   limitations defined in the URN syntax specification
   [I-D.ietf-urnbis-rfc2141bis-urn].

6.  Registering

5.  Defining a URN Namespace

6.1.  Formal Namespaces

   The registration policy for formal namespaces is IETF Review
   [RFC5226].

   The key steps for registration definition of a formal namespace are:

   1.  Submit an Internet-Draft that includes all ought to pay particular
   attention to:

   o  The purpose of the information
       described under Section 5.1.2 and Section 7 namespace.
   o  The syntax of this document.
   2.  Send the completed namespace definition template, along with a
       pointer to the Internet-Draft, to URNs assigned within the urn-nid@ietf.org discussion
       list namespace.
   o  The process for technical review.
   3.  If necessary to address comments received, repeat steps 1 assigning URNs within the namespace.
   o  The security implications of assigning and 2.
   4.  Ask using the assigned
      URNs.
   o  Optionally, the responsible Area Director to process for resolving URNs issued within the Internet-Draft
      namepace.

   The following sections explain these matters in greater detail.  For
   convenience, a template for publication as an RFC.  Note defining and registering a URN namespace
   is provided under Section 6.  This information can be especially
   helpful to entities that wish to request assignment of a URN in a
   namespace and to entities that the IESG can request
       further changes or direct discussion wish to designated working
       groups, area experts, etc.
   5.  If the IESG approves the document provide URN resolution for publication as an RFC, the
       IANA will register a
   namespace.

5.1.  Purpose

   The "Purpose" section of the requested NID.

   A registration can be revised template describes matters such as:

   o  The kinds of resources identified by updating URNs assigned within the RFC through normal IETF
   processes [RFC2606].
      namespace.

   o  Why it is preferable to use URNs rather than some other technology
      (e.g., URIs) and why existing URN namespace (if any) are not a
      good fit.

   o  The authors kinds of software applications that can use or resolve the revised document need to
   follow
      assigned URNs (e.g., by differentiating among disparate
      namespaces, identifying resources in a persistent fashion, or
      meaningfully resolving and accessing services associated with the same steps outlined above for new registrations.

6.2.  Informal Namespaces

   The registration policy for informal namespaces is First Come First
   Served [RFC5226].
      namespace).

   o  The key steps for registration scope of an informal the namespace are:

   1.  Write (public vs. private, global vs. local
      to a particular organization, nation, or industry).  For example,
      a completed namespace definition template (see Section 7).
       This can be done as part of an Internet-Draft.
   2.  Send the completed template claiming to the urn-nid@ietf.org discussion
       list for technical review.
   3.  If necessary deal in "social security numbers" ought to address comments received, repeat steps 1 and 2.
   4.  Once comments
      have been addressed a global scope and the review period has
       expired, send address all social security number
      structures, whereas a registration request URN scheme for a particular national system
      would need to IANA (via handle only that nation's social security numbers.

   o  How the
       iana@iana.org email address) with intended community (and the final template.

   Informal namespaces can also be revised by updating Internet community at large)
      will benefit from using or resolving the template and
   processing it as outlined above for new registrations.

7.  URN Namespace Definition Template

   Definition assigned URNs.

5.2.  Syntax

   The "Syntax" section of a URN namespace is accomplished by completing the
   following template.  In addition to providing a mechanism for
   defining template describes:

   o  A description of the structure of URNs assigned within the namespace, this
   information is designed to be useful for:

   o  entities seeking to have a URN assigned in a namespace (if
      applicable)
   o  entities seeking to provide URN resolvers for a namespace (if
      applicable)

   Providing a complete and accurate template is particularly helpful to
   communities that are evaluating
      conformance with the possibility fundamental URN syntax
      [I-D.ietf-urnbis-rfc2141bis-urn].  The structure might be
      described in terms of using a portion of formal definition (e.g., using Augmented
      BNF for Syntax Specifications (ABNF) as specified in [RFC5234]),
      an existing URN namespace rather than creating algorithm for generating conformant URNs, a new namespace.

   As described under Section 5.1.2, applications regular expression
      for formal URN
   namespaces MUST also document parsing the "Namespace Considerations",
   "Community Considerations", "Security Considerations", and "IANA
   Considerations".

   The information identifier into components, or by explaining that
      the structure is opaque.

   o  Any special character encoding rules for assigned URNs (e.g.,
      which character ought to always be provided used for single-quotes).

   o  Rules for determining equivalence between two identifiers in the template is as follows:

     Namespace ID:

        Requested
      namespace.  Such rules ought to always have the effect of IANA (formal) or assigned by IANA (informal).

     Registration Information:

        The version
      eliminating false negatives that might otherwise result from
      comparison.  If it is appropriate and date of the registration:

        -  Registration version number: starting with 1,
           incrementing by 1 with each new version
        -  Registration date: date submitted helpful, reference can be
      made to the IANA, using equivalence rules defined in the
           format YYYY-MM-DD

     Declared registrant URI specification
      [RFC3986].  Examples of equivalence rules include equivalence
      between uppercase and lowercase characters in the Namespace
      Specific String, between hyphenated and non-hyphenated groupings
      in the namespace:

        This includes:

        -  Registering organization
              Name
              Address
        -  Designated contact person
              Name
              Contact information
                (at least one of email address,
                phone number, postal address)

     Declaration identifier string, or between single-quotes and double-
      quotes.  (Note that these are not normative statements for any
      kind of syntactic structure:

        This section ought best practice related to outline any structural features handling of
        identifiers equivalences between
      characters in general; they are statements limited to this namespace.  At
      specific namespace only.)

   o  Any special considerations necessary for conforming with the very least, this
        description can be URN
      syntax.  This is particularly applicable in the case of legacy
      naming systems that are used to introduce terminology in the context of URNs.  For example,
      if a namespace is used in contexts other sections. than URNs, it might make
      use of characters that are reserved in the URN syntax.  This structure can also be used for
        determining realistic caching/shortcuts approaches;
        suitable caveats
      section ought to be provided.  If there are note any
        specific character encoding rules (e.g., which character
        ought such characters, and outline necessary
      mappings to always be used for single-quotes), these ought conform to URN syntax.  Normally, this will be listed here.  If handled
      by percent-encoding the namespace allows use of character as specified in the URI query component, URI fragment identifier component,
        or both,
      specification [RFC3986].

5.3.  Assignment

   The "Assignment" section of the template describes matters such usage needs as:

   o  Mechanisms or authorities for assigning URNs to be described here (in
        addition resources.  It
      ought to any other namespace-specific syntax, such
        as distinguishers make clear whether assignment is completely open (e.g.,
      following a particular algorithm), completely closed (e.g., for integral parts of resources
        identified by URNs within the namespace).

        At a high level, answers might include, but are not
      private organization), or limited to:

        -  A formal definition of the structure, e.g., in terms
           of Augmented BNF for Syntax Specifications (ABNF) as
           specified in [RFC5234]
        -  A regular expression for parsing the identifier into
           components, including naming various ways (e.g., delegated
      to authorities
        -  An algorithm for generating conformant URNs
        -  An explanation that the structure is opaque

     Relevant ancillary documentation:

        This section recognized by a particular organization); if
      limited, it ought to list any RFCs, specifications, or
        other published documentation that defines or explains
        all or part of the namespace structure.

        At a high level, answers might include, but are not limited to:

        -  Pointers explain how to specifications that define the syntax and
           semantics become an assigner of the namespace
        -  Mention
      identifiers or how to request assignemtn of documentation that describes the processes
           followed by an organization identifers from
      existing assignment authorities.

   o  Methods for ensuring that assigns URNs in the
           namespace
        -  Explanatory material describing within the namespace

     Identifier uniqueness considerations:

        This section ought to address the requirement that URNs are
        assigned uniquely -- i.e., they are assigned to at most one
        resource, and are not reassigned.

        (Note that the definition of "resource" is fairly broad; for unique.
      For example, information on "Today's Weather" identifiers might be considered assigned sequentially or in
      accordance with some well-defined process by a single resource, although the content is dynamic.)

        At a high level, answers might include, but are not limited to:

        -  Exposition of the structure of the identifiers, and
           partitioning of the space of identifiers amongst authority,
      assignment might be partitioned among delegated authorities which that
      are individually responsible for respecting uniqueness rules
        -  Description of a method rules, or
      URNs might be minted independently following an algorithm that
      itself guarantees uniqueness.

   o  Methods for assignment ensuring the longevity and maintainability of identifiers (e.g.,
           identifiers are assigned sequentially)
        -  An explanation that this information is withheld (i.e., the
      namespace is opaque)

     Identifier persistence considerations: and URNs assigned with the namespace.  Although non-reassignment non-
      reassignment of URN identifiers URNs ensures that a URN will persist in
      identifying a particular resource even after the "lifetime of the resource",
      resource" or the assignment authority, some consideration ought to
      be given to the persistence of the usability of the URN.  This is
      particularly important in the case of URN namespaces providing
      global resolution.

        At a high level, answers could include, but are not limited to:

        -  Quality of service considerations

     Process of identifier assignment:

        This

5.4.  Security

   The "Security" section ought to detail of the mechanisms and/or authorities
        for assigning URNs to resources.  It ought to make clear whether
        assignment is completely open or, if limited, how template describes any potential
   security-related issues with regard to become an
        assigner assignment, use, and
   resolution of identifiers within the namespace.  Examples of such
   issues include the consequences of producing false negatives and
   false positives during comparison for equivalence (see also
   [RFC6943]), leakage of private information when identifiers or how to get an identifer assigned by
        existing assignment authorities.

        At a high level, 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.,
   communicated on the Digital Object Identifier
           Foundation controls public Internet, the DOI assignment space potential for directory
   harvesting, and its
           delegation)
        -  Assignment is completely closed (e.g., various issues discussed in the guidelines for a private
           organization)

     Process
   security considerations in RFCs [RFC3552].

5.5.  Resolution

   The "Resolution" section specifies the rules for identifier resolution: resolution of URNs
   assigned within the namespace.  If a namespace is such URNs are intended to be accessible for global
        resolution, it
   resolvable, the namespace needs to be registered in an RDS (Resolution a Resolution
   Discovery System, System (RDS, see [RFC 2276]) [RFC2276]) such as DDDS.  Resolution then
   proceeds according to standard URI resolution processes,
        and as well as
   the mechanisms of the RDS.  What this  This section ought to
        outline is lists the
   requirements for becoming a recognized resolver of URNs in this the
   relevant namespace (and being so listed in the RDS registry).

        At a high level, answers
   Answers might include, but are not limited to:

        -

   o  The namespace is not listed with an RDS; therefore this section is
      not applicable
        - applicable.
   o  Resolution mirroring is completely open, with a mechanism for
      updating an appropriate RDS
        - RDS.
   o  Resolution is controlled by entities to which assignment has been delegated

     Rules for lexical equivalence:

        If there are particular algorithms
      delegated.

6.  Registration Template

6.1.  Namespace ID

   Requested of IANA (formal) or assigned by IANA (informal).

6.2.  Version

   The version of the registration, starting with 1 and incrementing by
   1 with each new version.

6.3.  Date

   The date when the registration is requested of IANA, using the format
   YYYY-MM-DD.

6.4.  Registrant

   The person or organization that has registered the NID, including the
   following information:

   o  The name and address of the registering organization.
   o  The name and contact information (email, phone number, and/or
      postal address) of the designated contact person.

6.5.  Purpose

   Described under Section 5.1 of this document.

6.6.  Syntax

   Described under Section 5.2 of this document.

6.7.  Assignment

   Described under Section 5.3 of this document.

6.8.  Resolution

   Described under Section 5.5 of this document.

6.9.  Documentation

   Any Internet-Draft, RFC, specification, or other published document
   that defines or explains the namespace.

7.  Registering a URN Namespace

7.1.  Formal Namespaces

   The registration policy for determining equivalence
        between two identifiers formal namespaces is Expert Review as
   defined in the underlying "IANA Considerations" document [RFC5226].  The key
   steps for registration of a formal namespace (hence, in are:

   1.  Fill out the URN string itself), rules namespace registration template (see Section 6).
       This can be provided here.  Such rules
        ought to always have the effect done as part of eliminating false negatives an Internet-Draft or a specification
       in another series, although that might otherwise result from comparison.

        If it is appropriate and helpful not necessary.
   2.  Send the completed template to do so, reference can be
        made the urn-nid@ietf.org discussion
       list for technical review.
   3.  If necessary to address comments received, repeat steps 1 and 2.
   4.  If the equivalence rules defined in designated experts approve the URI specification
        [RFC3986].

        Some examples include:

        -  Equivalence between uppercase and lowercase characters in request, the Namespace Specific String
        -  Equivalence between hyphenated and non-hyphenated groupings
           in IANA will
       register 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 related to handling of equivalences between
        characters in general; they are statements limited in scope to
        reflecting requested NID.

   A formal namespace registration can be revised by updating the rules
   registration template, following the same steps outlined above for this specific namespace only.

     Conformance with URN syntax:

        This section ought to outline any special considerations
        necessary
   new registrations.

7.2.  Informal Namespaces

   The registration policy for conforming with the URN syntax.  This informal namespaces is
        particularly applicable in the case of legacy naming
        systems that are used in the context First Come First
   Served [RFC5226].  The key steps for registration of URNs.

        For example, if an informal
   namespace are:

   1.  Write a completed namespace is used in contexts other than URNs, definition template (see Section 6).
   2.  Send it might make use of characters that are reserved in the URN
        syntax.

        This section ought to flag any such characters, and outline
        necessary mappings to conform the urn-nid@ietf.org discussion list for feedback.
   3.  Once the review period has expired, send the final template to URN syntax.  Normally, this
        will
       IANA (via the iana@iana.org email address).

   An informal namespace registration can be handled revised by percent-encoding updating the character as specified
        in
   registration template, following the URI specification [RFC3986].

     Validation mechanism:

        Apart from attempting resolution of a URN, a URN namespace may
        provide mechanisms same steps outlined above for "validating" a URN -- i.e., determining
        whether a given string is currently a validly-assigned URN.
        There are two issues here: 1) users ought
   new registrations.

8.  Guidelines for Designated Experts

   Experience to date with NID registration requests has shown that
   registrants sometimes do not "guess" URNs in
        a namespace; 2) when initially understand some of the
   subtleties of URN namespaces, and that defining the namespace is based on an existing
        identifier system, it might not be in the case that all existing
        identifiers are assigned on Day 0.  The reasonable expectation
        is that
   form of a specification enables the resource associated with each resulting URN is
        somehow related registrants to clearly formulate
   their "contract" with the thing identified by intended user community.  Therefore,
   although the original
        identifier system, but those resources might not exist registration policy for each
        original identifier.  For example, even if formal namespaces is Expert
   Review and a URN namespace were
        defined based on telephone numbers, it specification is not clear that all
        telephone numbers would immediately become "valid" URNs
        resolvable using whatever mechanisms required, the designated experts
   for NID registration requests are described as part of encouraged to prefer that a
   specification exist documenting the namespace registration.

        Validation mechanisms might be:

        -  A syntax grammar
        -  An online service
        -  An offline service

     Scope: definition.

9.  IANA Considerations

   This section ought to outline the scope of the use of document outlines the
        identifiers in this namespace.  Apart from considerations of
        private vs. public processes for registering URN namespaces, this section is critical in
        evaluating
   and has implications for the applicability of a requested NID.  For example,
        a namespace claiming to deal IANA in "social security numbers"
        ought terms of registries to have a global scope and address be
   maintained.  In all social security
        number structures (unlikely).  On cases, the other hand, at a national
        level, it is reasonable IANA ought to propose a URN namespace for "this
        nation's social security numbers".

8. assign the appropriate
   NID (formal or informal) once the procedures outlined in this
   document have been completed.

10.  Security Considerations

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

   The definition of a URN namespace needs to account for potential
   security issues related to assignment, use, and resolution of
   identifiers within the namespace; see Section 5.1.2 for further
   discussion.

9.  IANA Considerations

   This document outlines the processes for registering URN namespaces,
   and has implications for the IANA in terms of registries to be
   maintained.  In all cases, the IANA ought to assign the appropriate
   NID (formal or informal) once the procedures outlined in this
   document have been completed.

10. namespace.

11.  References

10.1.

11.1.  Normative References

   [I-D.ietf-urnbis-rfc2141bis-urn]
              Saint-Andre, P. and R. Moats, P., "Uniform Resource Name (URN) Syntax", draft-ietf-urnbis-rfc2141bis-urn-05
              draft-ietf-urnbis-rfc2141bis-urn-06 (work in progress), July
              August 2013.

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

10.2.

11.2.  Informative References

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

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

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

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

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

   [RFC6943]  Thaler, D., "Issues in Identifier Comparison for Security
              Purposes", RFC 6943, May 2013.

   [RFC6963]  Saint-Andre, P., "A Uniform Resource Name (URN) Namespace
              for Examples", BCP 183, RFC 6963, May 2013.

Appendix A.  Changes from RFC 3406

   Although on the surface it might appear that this

   This document is
   significantly different makes the following substantive changes from [RFC3406], in general it only modifies [RFC3406]:

   o  Relaxes the order registration policy for formal namespaces from "IETF
      Review" to "Expert Review" [RFC5226].
   o  Removes the category of presentation, experimental namespaces, consistent with
      [RFC6648].
   o  Simplifies the intent of making it easier for
   interested parties to define and register URN namespaces. registration template.

   In addition, some of the text was has been updated to be consistent with
   the definition of Uniform Resource Identifiers (URIs) [RFC3986] and
   the processes for registering information with the IANA [RFC5226], as
   well as more modern guidance with regard to security issues [RFC3552]
   and identifier comparison [RFC6943].  The only major substantive
   change was removing

Appendix B.  Contributors

   RFC 3406, which provided the category of experimental namespaces,
   consistent with [RFC6648].

Authors' Addresses basis for this document, was authored by
   Leslie Daigle, Dirk-Willem van Gulik, Renato Iannella, and Patrik
   Faltstrom.  Their work is gratefully acknowledged.

Appendix C.  Acknowledgements

   Thanks to Marc Blanchet, Juha Hakala, John Klensin, and Barry Leiba
   for their input.

Author's Address

   Peter Saint-Andre (editor)
   Cisco Systems, Inc.
   1899 Wynkoop Street, Suite 600
   Denver, CO  80202
   USA

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

   Leslie Daigle
   Thinking Cat Enterprises

   Dirk-Willem van Gulik
   WebWeaving

   Renato Iannella
   Semantic Identity

   Patrick Faltstrom
   Netnod