draft-ietf-urnbis-rfc3406bis-urn-ns-reg-07.txt   draft-ietf-urnbis-rfc3406bis-urn-ns-reg-08.txt 
URNBIS P. Saint-Andre URNBIS P. Saint-Andre
Internet-Draft Cisco Systems, Inc. Internet-Draft January 24, 2014
Obsoletes: 3406 (if approved) November 13, 2013 Obsoletes: 3406 (if approved)
Intended status: BCP Intended status: BCP
Expires: May 17, 2014 Expires: July 28, 2014
Uniform Resource Name (URN) Namespace Definition Mechanisms Uniform Resource Name (URN) Namespace Definition Mechanisms
draft-ietf-urnbis-rfc3406bis-urn-ns-reg-07 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-08
Abstract Abstract
This document supplements the Uniform Resource Name (URN) syntax This document supplements the Uniform Resource Name (URN) syntax
specification by defining the concept of a URN namespace, as well as specification by defining the concept of a URN namespace, as well as
mechanisms for defining and registering such namespaces. This mechanisms for defining and registering such namespaces. This
document obsoletes RFC 3406. document obsoletes RFC 3406.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 17, 2014. This Internet-Draft will expire on July 28, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 19 skipping to change at page 2, line 19
3. What is a URN Namespace? . . . . . . . . . . . . . . . . . . . 4 3. What is a URN Namespace? . . . . . . . . . . . . . . . . . . . 4
4. URN Namespace Types . . . . . . . . . . . . . . . . . . . . . 5 4. URN Namespace Types . . . . . . . . . . . . . . . . . . . . . 5
4.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 5 4.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 5
4.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 6 4.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 6
5. Defining a URN Namespace . . . . . . . . . . . . . . . . . . . 6 5. Defining a URN Namespace . . . . . . . . . . . . . . . . . . . 6
5.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Assignment . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Assignment . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.5. Resolution . . . . . . . . . . . . . . . . . . . . . . . . 9 5.5. Resolution . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Registration Template . . . . . . . . . . . . . . . . . . . . 10 6. Registration Template . . . . . . . . . . . . . . . . . . . . 9
6.1. Namespace ID . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Namespace ID . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Version . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Version . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Registrant . . . . . . . . . . . . . . . . . . . . . . . . 10 6.4. Registrant . . . . . . . . . . . . . . . . . . . . . . . . 10
6.5. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.5. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.7. Assignment . . . . . . . . . . . . . . . . . . . . . . . . 10 6.7. Assignment . . . . . . . . . . . . . . . . . . . . . . . . 10
6.8. Resolution . . . . . . . . . . . . . . . . . . . . . . . . 10 6.8. Resolution . . . . . . . . . . . . . . . . . . . . . . . . 10
6.9. Documentation . . . . . . . . . . . . . . . . . . . . . . 10 6.9. Documentation . . . . . . . . . . . . . . . . . . . . . . 10
7. Registering a URN Namespace . . . . . . . . . . . . . . . . . 11 7. Registering a URN Namespace . . . . . . . . . . . . . . . . . 10
7.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 11 7.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 10
7.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 11 7.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 11
8. Guidelines for Designated Experts . . . . . . . . . . . . . . 11 8. Guidelines for Designated Experts . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Changes from RFC 3406 . . . . . . . . . . . . . . . . 13 Appendix A. Changes from RFC 3406 . . . . . . . . . . . . . . . . 13
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 13 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 13
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
A Uniform Resource Name (URN) [I-D.ietf-urnbis-rfc2141bis-urn] is a A Uniform Resource Name (URN) [I-D.ietf-urnbis-rfc2141bis-urn] is a
Uniform Resource Identifier (URI) [RFC3986] that is intended to serve Uniform Resource Identifier (URI) [RFC3986] that is intended to serve
as a persistent, location-independent resource identifier. This as a persistent, location-independent resource identifier. This
document supplements the Uniform Resource Name (URN) syntax document supplements the Uniform Resource Name (URN) syntax
specification [I-D.ietf-urnbis-rfc2141bis-urn] by defining: specification [I-D.ietf-urnbis-rfc2141bis-urn] by defining:
o The concept of a URN namespace. 1. The concept of a URN namespace.
o A mechanism for defining a URN namespace and associating it with a 2. A mechanism for defining a URN namespace and associating it with
public identifier (called a Namespace ID or "NID"). a public identifier (called a Namespace ID or "NID").
o Procedures for registering NIDs with the Internet Assigned Numbers 3. Procedures for registering NIDs with the Internet Assigned
Authority (IANA). Numbers Authority (IANA).
Syntactically, the NID follows the 'urn' scheme name. For instance, Syntactically, the NID follows the 'urn' scheme name. For instance,
a URN in the 'example' namespace [RFC6963] might be of the form a URN in the 'example' namespace [RFC6963] might be of the form
"urn:example:foo". "urn:example:foo".
This document rests on two key assumptions: This document rests on two key assumptions:
1. Assignment of a URN is a managed process. 1. Assignment of a URN is a managed process.
A string that conforms to the URN syntax is not necessarily a A string that conforms to the URN syntax is not necessarily a
skipping to change at page 4, line 18 skipping to change at page 4, line 18
[RFC2119]. [RFC2119].
3. What is a URN Namespace? 3. What is a URN Namespace?
A URN namespace is a collection of identifiers that are (1) unique, A URN namespace is a collection of identifiers that are (1) unique,
(2) assigned in a consistent way, and (3) assigned according to a (2) assigned in a consistent way, and (3) assigned according to a
common definition. common definition.
1. The "uniqueness" constraint means that an identifier within the 1. The "uniqueness" constraint means that an identifier within the
namespace is never assigned to more than one resource and never namespace is never assigned to more than one resource and never
reassigned to a different resource. reassigned to a different resource, even if the identifier itself
is deprecated or becomes obsolete.
2. The "consistent assignment" constraint means that an identifier 2. The "consistent assignment" constraint means that an identifier
within the namespace is assigned by an organization or minted in within the namespace is assigned by an organization or created in
accordance with a process or algorithm that is always followed. accordance with a process or algorithm that is always followed.
3. The "common definition" constraint means that there are clear 3. The "common definition" constraint means that there are clear
definitions for the syntax of identifiers within the namespace definitions for the syntax of identifiers within the namespace
and the process of assigning or minting them. and the process of assigning or creating them.
A URN namespace is identified by a particular NID in order to ensure A URN namespace is identified by a particular NID in order to ensure
the global uniqueness of URNs and, optionally, to provide a cue the global uniqueness of URNs and, optionally, to provide a cue
regarding the structure of URNs assigned within a namespace. regarding the structure of URNs assigned within a namespace.
With regard to global uniqueness, using different NIDs for different With regard to global uniqueness, using different NIDs for different
collections of identifiers ensures that no two URNs will be the same collections of identifiers ensures that no two URNs will be the same
for different resources, since each collection is required to for different resources, since each collection is required to
uniquely assign each identifier. However, a single resource can have uniquely assign each identifier. However, a single resource can have
more than one URN assigned to it for different purposes (e.g., some more than one URN assigned to it for different purposes (e.g., some
skipping to change at page 5, line 5 skipping to change at page 5, line 5
development of an identifier structure (and thereby a collection of development of an identifier structure (and thereby a collection of
identifiers) depends on the requirements of the community defining identifiers) depends on the requirements of the community defining
the identifiers, how the identifiers will be assigned and used, etc. the identifiers, how the identifiers will be assigned and used, etc.
These issues are beyond the scope of URN syntax and the general rules These issues are beyond the scope of URN syntax and the general rules
for URN namespaces, because they are specific to the community for URN namespaces, because they are specific to the community
defining a namespace (e.g., the bibliographic and publishing defining a namespace (e.g., the bibliographic and publishing
communities in the case of the 'ISBN' and 'ISSN' namespaces, or the communities in the case of the 'ISBN' and 'ISSN' namespaces, or the
developers of extensions to the Extensible Messaging and Presence developers of extensions to the Extensible Messaging and Presence
Protocol in the case of the 'XMPP' namespace). Protocol in the case of the 'XMPP' namespace).
URN namespaces inherit certain rights and responsibilities, e.g.: URN namespaces inherit certain rights and responsibilities by the
nature of URNs [I-D.ietf-urnbis-rfc2141bis-urn], e.g.:
o They uphold the general principles of a well-managed URN namespace 1. They uphold the general principles of a well-managed URN
by providing persistent identification of resources and unique namespace by providing persistent identification of resources and
assignment of identifier strings. unique assignment of identifier strings.
o They can be registered in global registration services. 2. They can be registered in global registration services.
4. URN Namespace Types 4. URN Namespace Types
There are two types of URN namespace: formal and informal. These are There are two types of URN namespace: formal and informal. These are
distinguished by the expected level of service, the information distinguished by the expected level of service, the information
needed to define the namespace, and the procedures for registration. needed to define the namespace, and the procedures for registration.
Because the majority of the namespaces registered so far have been Because the majority of the namespaces registered so far have been
formal, this document concentrates on formal namespaces. formal, this document concentrates on formal namespaces.
Note: [RFC3406] defined a third type of "experimental namespaces", Note: [RFC3406] defined a third type of "experimental namespaces",
denoted by prefixing the namespace identifier with the string "X-". denoted by prefixing the namespace identifier with the string "X-".
Consistent with [RFC6648], this specification removes the Consistent with [RFC6648], this specification removes the
experimental category. experimental category.
4.1. Formal Namespaces 4.1. Formal Namespaces
A formal namespace provides benefit to some subset of users on the A formal namespace provides benefit to some subset of users on the
Internet (i.e., not limited to users in communities or networks not Internet (e.g., it would not make sense for a formal namespace to be
connected to the Internet). For example, it would be inappropriate used only by a community or network that is not connected to the
for a NID to effectively force someone to use a proprietary network Internet). For example, it would be inappropriate for a NID to
or service not open to the general Internet user. The intent is effectively force someone to use a proprietary network or service not
that, while the community of those who might actively use the names open to the general Internet user. The intent is that, while the
assigned within that NID might be small, the potential use of community of those who might actively use the names assigned within
identifiers within that NID is open to any user on the Internet. that NID might be small, the potential use of identifiers within that
Formal NIDs might be appropriate when some aspects are not fully NID is open to any user on the Internet. Formal NIDs might be
open. For example, a namespace might make use of a fee-based, appropriate when some aspects are not fully open. For example, a
privately managed, or proprietary registry for assignment of URNs in namespace might make use of a fee-based, privately managed, or
the namespace. However, it might still benefit some Internet users proprietary registry for assignment of URNs in the namespace.
if the associated services have openly-published access protocols. However, it might still benefit some Internet users if the associated
services have openly-published access protocols.
An organization that will assign URNs within a formal namespace ought An organization that will assign URNs within a formal namespace ought
to meet the following criteria: to meet the following criteria:
o Organizational stability and the ability to maintain the URN 1. Organizational stability and the ability to maintain the URN
namespace for a long time; absent such evidence, it ought to be namespace for a long time; absent such evidence, it ought to be
clear how the namespace can remain viable if the organization can clear how the namespace can remain viable if the organization can
no longer maintain the namespace. no longer maintain the namespace.
o Competency in name assignment. This will improve the likelihood
of persistence (e.g. to minimize the likelihood of conflicts).
o Commitment to not reassigning existing names and to allowing old 2. Competency in name assignment. This will improve the likelihood
names to continue to be valid, even if the owners or assignees of of persistence (e.g. to minimize the likelihood of conflicts).
those names are no longer members or customers of that 3. Commitment to not reassigning existing names and to allowing old
organization. With regard to URN resolution [RFC2276], this does names to continue to be valid, even if the owners or assignees of
not mean that there needs to be resolution of such names, only those names are no longer members or customers of that
that the names will not resolve to false or stale information. organization. With regard to URN resolution [RFC2276], this does
not mean that there needs to be resolution of such names, only
that the names will not resolve to false or stale information.
A formal namespace establishes a particular NID, subject to the A formal namespace establishes a particular NID, subject to the
following constraints (above and beyond the syntax rules specified in following constraints (above and beyond the syntax rules specified in
[I-D.ietf-urnbis-rfc2141bis-urn]): [I-D.ietf-urnbis-rfc2141bis-urn]):
o It MUST NOT be an already-registered NID. 1. It MUST NOT be an already-registered NID.
o It MUST NOT start with "urn-" (which is reserved for informal 2. It MUST NOT start with "urn-" (which is reserved for informal
namespaces). namespaces).
o It MUST be more than two characters long. 3. It MUST be more than two characters long.
o It MUST NOT start with "XY-", where "XY" is any combination of two 4. It MUST NOT start with "XY-", where "XY" is any combination of
ASCII letters. two ASCII letters.
All two-letter combinations, and all two-letter combinations followed All two-letter combinations, and all two-letter combinations followed
by "-" and any sequence of valid NID characters, are reserved for by "-" and any sequence of valid NID characters, are reserved for
potential use as countrycode-based NIDs for eventual national potential use as countrycode-based NIDs for eventual national
registrations of URN namespaces. The definition and scoping of rules registrations of URN namespaces. The definition and scoping of rules
for allocation of responsibility for such countrycode-based for allocation of responsibility for such countrycode-based
namespaces is beyond the scope of this document. namespaces is beyond the scope of this document.
4.2. Informal Namespaces 4.2. Informal Namespaces
Informal namespaces are full-fledged URN namespaces, with all the Informal namespaces are full-fledged URN namespaces, with all the
associated rights and responsibilities. Informal namespaces differ associated rights and responsibilities. Informal namespaces differ
from formal namespaces in the process for assigning a NID: IANA will from formal namespaces in the process for assigning a NID: for an
assign an alphanumeric NID (e.g., "urn-7") to informal namespaces, informal namespace, IANA will assign an NID consisting of the string
with the following syntax: 'urn-' followed by one or more digits (e.g., "urn-7"). Thus the
syntax of an informal namespace is:
"urn-" <number> "urn-" <number>
The only restrictions on <number> are that it (1) consist strictly of The only restrictions on <number> are that it (1) consist strictly of
ASCII digits and (2) not cause the NID to exceed the length ASCII digits and (2) not cause the NID to exceed the length
limitations defined in the URN syntax specification limitations defined in the URN syntax specification
[I-D.ietf-urnbis-rfc2141bis-urn]. [I-D.ietf-urnbis-rfc2141bis-urn].
5. Defining a URN Namespace 5. Defining a URN Namespace
The definition of a formal namespace ought to pay particular The definition of a formal namespace ought to pay particular
attention to: attention to:
o The purpose of the namespace. 1. The purpose of the namespace.
o The syntax of URNs assigned within the namespace. 2. The syntax of URNs assigned within the namespace.
o The process for assigning URNs within the namespace. 3. The process for assigning URNs within the namespace.
o The security implications of assigning and using the assigned 4. The security implications of assigning and using the assigned
URNs. URNs.
o Optionally, the process for resolving URNs issued within the 5. Optionally, the process for resolving URNs issued within the
namepace. namepace.
The following sections explain these matters in greater detail. For The following sections explain these matters in greater detail. For
convenience, a template for defining and registering a URN namespace convenience, a template for defining and registering a URN namespace
is provided under Section 6. This information can be especially is provided under Section 6. This information can be especially
helpful to entities that wish to request assignment of a URN in a helpful to entities that wish to request assignment of a URN in a
namespace and to entities that wish to provide URN resolution for a namespace and to entities that wish to provide URN resolution for a
namespace. namespace.
5.1. Purpose 5.1. Purpose
The "Purpose" section of the template describes matters such as: The "Purpose" section of the template describes matters such as:
o The kinds of resources identified by URNs assigned within the 1. The kinds of resources identified by URNs assigned within the
namespace. namespace.
o Why it is preferable to use URNs rather than some other technology 2. Why it is preferable to use URNs rather than some other
(e.g., URIs) and why existing URN namespace (if any) are not a technology (e.g., URIs) and why no existing URN namespace is a
good fit. good fit.
o The kinds of software applications that can use or resolve the 3. The kinds of software applications that can use or resolve the
assigned URNs (e.g., by differentiating among disparate assigned URNs (e.g., by differentiating among disparate
namespaces, identifying resources in a persistent fashion, or namespaces, identifying resources in a persistent fashion, or
meaningfully resolving and accessing services associated with the meaningfully resolving and accessing services associated with the
namespace). namespace).
o The scope of the namespace (public vs. private, global vs. local 4. The scope of the namespace (public vs. private, global vs. local
to a particular organization, nation, or industry). For example, to a particular organization, nation, or industry). For example,
a namespace claiming to deal in "social security numbers" ought to a namespace claiming to deal in "national identification numbers"
have a global scope and address all social security number ought to have a global scope and address all identity number
structures, whereas a URN scheme for a particular national system structures, whereas a URN scheme for a particular national
would need to handle only that nation's social security numbers. identification number system would need to handle only the
structure for that nation's identity numbers.
o How the intended community (and the Internet community at large) 5. How the intended community (and the Internet community at large)
will benefit from using or resolving the assigned URNs. will benefit from using or resolving the assigned URNs.
5.2. Syntax 5.2. Syntax
The "Syntax" section of the template describes: The "Syntax" section of the template describes:
o A description of the structure of URNs within the namespace, in 1. A description of the structure of URNs within the namespace, in
conformance with the fundamental URN syntax conformance with the fundamental URN syntax
[I-D.ietf-urnbis-rfc2141bis-urn]. The structure might be [I-D.ietf-urnbis-rfc2141bis-urn]. The structure might be
described in terms of a formal definition (e.g., using Augmented described in terms of a formal definition (e.g., using Augmented
BNF for Syntax Specifications (ABNF) as specified in [RFC5234]), BNF for Syntax Specifications (ABNF) as specified in [RFC5234]),
an algorithm for generating conformant URNs, a regular expression an algorithm for generating conformant URNs, a regular expression
for parsing the identifier into components, or by explaining that for parsing the identifier into components, or by explaining that
the structure is opaque. the structure is opaque.
o Any special character encoding rules for assigned URNs (e.g., 2. Any special character encoding rules for assigned URNs (e.g.,
which character ought to always be used for single-quotes). which character ought to always be used for single-quotes).
o Rules for determining equivalence between two identifiers in the 3. Rules for determining equivalence between two identifiers in the
namespace. Such rules ought to always have the effect of namespace. Such rules ought to always have the effect of
eliminating false negatives that might otherwise result from eliminating false negatives that might otherwise result from
comparison. If it is appropriate and helpful, reference can be comparison. If it is appropriate and helpful, reference can be
made to the equivalence rules defined in the URI specification made to the equivalence rules defined in the URI specification
[RFC3986]. Examples of equivalence rules include equivalence [RFC3986]. Examples of equivalence rules include equivalence
between uppercase and lowercase characters in the Namespace between uppercase and lowercase characters in the Namespace
Specific String, between hyphenated and non-hyphenated groupings Specific String, between hyphenated and non-hyphenated groupings
in the identifier string, or between single-quotes and double- in the identifier string, or between single-quotes and double-
quotes. (Note that these are not normative statements for any quotes. (Note that these are not normative statements for any
kind of best practice related to handling of equivalences between kind of best practice related to handling of equivalences between
characters in general; they are statements limited to this characters in general; they are statements limited to one
specific namespace only.) particular namespace only.)
o Any special considerations necessary for conforming with the URN 4. Any special considerations necessary for conforming with the URN
syntax. This is particularly applicable in the case of legacy syntax. This is particularly applicable in the case of legacy
naming systems that are used in the context of URNs. For example, naming systems that are used in the context of URNs. For
if a namespace is used in contexts other than URNs, it might make example, if a namespace is used in contexts other than URNs, it
use of characters that are reserved in the URN syntax. This might make use of characters that are reserved in the URN syntax.
section ought to note any such characters, and outline necessary This section ought to note any such characters, and outline
mappings to conform to URN syntax. Normally, this will be handled necessary mappings to conform to URN syntax. Normally, this will
by percent-encoding the character as specified in the URI be handled by percent-encoding the character as specified in the
specification [RFC3986]. URI specification [RFC3986].
5.3. Assignment 5.3. Assignment
The "Assignment" section of the template describes matters such as: The "Assignment" section of the template describes matters such as:
o Mechanisms or authorities for assigning URNs to resources. It 1. Mechanisms or authorities for assigning URNs to resources. It
ought to make clear whether assignment is completely open (e.g., ought to make clear whether assignment is completely open (e.g.,
following a particular algorithm), completely closed (e.g., for a following a particular algorithm), completely closed (e.g., for a
private organization), or limited in various ways (e.g., delegated private organization), or limited in various ways (e.g.,
to authorities recognized by a particular organization); if delegated to authorities recognized by a particular
limited, it ought to explain how to become an assigner of organization); if limited, it ought to explain how to become an
identifiers or how to request assignemtn of identifers from assigner of identifiers or how to request assignemtn of
existing assignment authorities. identifers from existing assignment authorities.
o Methods for ensuring that URNs within the namespace are unique.
For example, identifiers might be assigned sequentially or in
accordance with some well-defined process by a single authority,
assignment might be partitioned among delegated authorities that
are individually responsible for respecting uniqueness rules, or
URNs might be minted independently following an algorithm that
itself guarantees uniqueness.
o Methods for ensuring the longevity and maintainability of the 2. Methods for ensuring that URNs within the namespace are unique.
namespace and URNs assigned with the namespace. Although non- For example, identifiers might be assigned sequentially or in
reassignment of URNs ensures that a URN will persist in accordance with some well-defined process by a single authority,
identifying a particular resource even after the "lifetime of the assignment might be partitioned among delegated authorities that
resource" or the assignment authority, some consideration ought to are individually responsible for respecting uniqueness rules, or
be given to the persistence of the usability of the URN. This is URNs might be created independently following an algorithm that
particularly important in the case of URN namespaces providing itself guarantees uniqueness.
global resolution.
5.4. Security 5.4. Security
The "Security" section of the template describes any potential The "Security" section of the template describes any potential
security-related issues with regard to assignment, use, and security-related issues with regard to assignment, use, and
resolution of identifiers within the namespace. Examples of such resolution of identifiers within the namespace. Examples of such
issues include the consequences of producing false negatives and issues include the consequences of producing false negatives and
false positives during comparison for equivalence (see also false positives during comparison for equivalence (see also
[RFC6943]), leakage of private information when identifiers are [RFC6943]), leakage of private information when identifiers are
communicated on the public Internet, the potential for directory communicated on the public Internet, the potential for directory
skipping to change at page 9, line 46 skipping to change at page 9, line 37
The "Resolution" section specifies the rules for resolution of URNs The "Resolution" section specifies the rules for resolution of URNs
assigned within the namespace. If such URNs are intended to be assigned within the namespace. If such URNs are intended to be
resolvable, the namespace needs to be registered in a Resolution resolvable, the namespace needs to be registered in a Resolution
Discovery System (RDS, see [RFC2276]) such as DDDS. Resolution then Discovery System (RDS, see [RFC2276]) such as DDDS. Resolution then
proceeds according to standard URI resolution processes, as well as proceeds according to standard URI resolution processes, as well as
the mechanisms of the RDS. This section ought to lists the the mechanisms of the RDS. This section ought to lists the
requirements for becoming a recognized resolver of URNs in the requirements for becoming a recognized resolver of URNs in the
relevant namespace (and being so listed in the RDS registry). relevant namespace (and being so listed in the RDS registry).
Answers might include, but are not limited to: Answers might include, but are not limited to:
o The namespace is not listed with an RDS; therefore this section is 1. The namespace is not listed with an RDS; therefore this section
not applicable. is not applicable.
o Resolution mirroring is completely open, with a mechanism for 2. Resolution mirroring is completely open, with a mechanism for
updating an appropriate RDS. updating an appropriate RDS.
o Resolution is controlled by entities to which assignment has been 3. Resolution is controlled by entities to which assignment has been
delegated. delegated.
6. Registration Template 6. Registration Template
6.1. Namespace ID 6.1. Namespace ID
Requested of IANA (formal) or assigned by IANA (informal). Requested of IANA (formal) or assigned by IANA (informal).
6.2. Version 6.2. Version
The version of the registration, starting with 1 and incrementing by The version of the registration, starting with 1 and incrementing by
skipping to change at page 10, line 48 skipping to change at page 10, line 42
6.7. Assignment 6.7. Assignment
Described under Section 5.3 of this document. Described under Section 5.3 of this document.
6.8. Resolution 6.8. Resolution
Described under Section 5.5 of this document. Described under Section 5.5 of this document.
6.9. Documentation 6.9. Documentation
Any Internet-Draft, RFC, specification, or other published document A pointer to an Internet-Draft, RFC, non-IETF specification, or other
that defines or explains the namespace. published document that provides further information about the
namespace.
7. Registering a URN Namespace 7. Registering a URN Namespace
7.1. Formal Namespaces 7.1. Formal Namespaces
The registration policy for formal namespaces is Expert Review as The registration policy for formal namespaces is Expert Review as
defined in the "IANA Considerations" document [RFC5226]. The key defined in the "IANA Considerations" document [RFC5226]. The key
steps for registration of a formal namespace are: steps for registration of a formal namespace are:
1. Fill out the namespace registration template (see Section 6). 1. Fill out the namespace registration template (see Section 6).
skipping to change at page 12, line 30 skipping to change at page 12, line 25
The definition of a URN namespace needs to account for potential The definition of a URN namespace needs to account for potential
security issues related to assignment, use, and resolution of security issues related to assignment, use, and resolution of
identifiers within the namespace. identifiers within the namespace.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-urnbis-rfc2141bis-urn] [I-D.ietf-urnbis-rfc2141bis-urn]
Saint-Andre, P., "Uniform Resource Name (URN) Syntax", Saint-Andre, P., Ed., "Uniform Resource Name (URN)
draft-ietf-urnbis-rfc2141bis-urn-06 (work in progress), Syntax", draft-ietf-urnbis-rfc2141bis-urn-07 (work in
August 2013. progress), January 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
skipping to change at page 13, line 32 skipping to change at page 13, line 28
[RFC6943] Thaler, D., "Issues in Identifier Comparison for Security [RFC6943] Thaler, D., "Issues in Identifier Comparison for Security
Purposes", RFC 6943, May 2013. Purposes", RFC 6943, May 2013.
[RFC6963] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace [RFC6963] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace
for Examples", BCP 183, RFC 6963, May 2013. for Examples", BCP 183, RFC 6963, May 2013.
Appendix A. Changes from RFC 3406 Appendix A. Changes from RFC 3406
This document makes the following substantive changes from [RFC3406]: This document makes the following substantive changes from [RFC3406]:
o Relaxes the registration policy for formal namespaces from "IETF 1. Relaxes the registration policy for formal namespaces from "IETF
Review" to "Expert Review" [RFC5226]. Review" to "Expert Review" [RFC5226].
o Removes the category of experimental namespaces, consistent with 2. Removes the category of experimental namespaces, consistent with
[RFC6648]. [RFC6648].
o Simplifies the registration template. 3. Simplifies the registration template.
In addition, some of the text has been updated to be consistent with In addition, some of the text has been updated to be consistent with
the definition of Uniform Resource Identifiers (URIs) [RFC3986] and the definition of Uniform Resource Identifiers (URIs) [RFC3986] and
the processes for registering information with the IANA [RFC5226], as the processes for registering information with the IANA [RFC5226], as
well as more modern guidance with regard to security issues [RFC3552] well as more modern guidance with regard to security issues [RFC3552]
and identifier comparison [RFC6943]. and identifier comparison [RFC6943].
Appendix B. Contributors Appendix B. Contributors
RFC 3406, which provided the basis for this document, was authored by RFC 3406, which provided the basis for this document, was authored by
Leslie Daigle, Dirk-Willem van Gulik, Renato Iannella, and Patrik Leslie Daigle, Dirk-Willem van Gulik, Renato Iannella, and Patrik
Faltstrom. Their work is gratefully acknowledged. Faltstrom. Their work is gratefully acknowledged.
Appendix C. Acknowledgements Appendix C. Acknowledgements
Thanks to Marc Blanchet, Juha Hakala, John Klensin, and Barry Leiba Thanks to Marc Blanchet, Juha Hakala, Paul Jones, John Klensin, and
for their input. Barry Leiba for their input.
Author's Address Author's Address
Peter Saint-Andre Peter Saint-Andre
Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600
Denver, CO 80202
USA
Phone: +1-303-308-3282 Email: ietf@stpeter.im
Email: psaintan@cisco.com
 End of changes. 41 change blocks. 
161 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/