draft-ietf-urnbis-rfc3406bis-urn-ns-reg-06.txt   draft-ietf-urnbis-rfc3406bis-urn-ns-reg-07.txt 
URNBIS P. Saint-Andre, Ed. URNBIS P. Saint-Andre
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Obsoletes: 3406 (if approved) L. Daigle Obsoletes: 3406 (if approved) November 13, 2013
Intended status: BCP Thinking Cat Enterprises Intended status: BCP
Expires: January 13, 2014 D. van Gulik Expires: May 17, 2014
WebWeaving
R. Iannella
Semantic Identity
P. Faltstrom
Netnod
July 12, 2013
Uniform Resource Name (URN) Namespace Definition Mechanisms Uniform Resource Name (URN) Namespace Definition Mechanisms
draft-ietf-urnbis-rfc3406bis-urn-ns-reg-06 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-07
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 40 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 January 13, 2014. This Internet-Draft will expire on May 17, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 20 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
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. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 7 5.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1.2. Specification . . . . . . . . . . . . . . . . . . . . 7 5.3. Assignment . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 8 5.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Registering a URN Namespace . . . . . . . . . . . . . . . . . 9 5.5. Resolution . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 9 6. Registration Template . . . . . . . . . . . . . . . . . . . . 10
6.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 9 6.1. Namespace ID . . . . . . . . . . . . . . . . . . . . . . . 10
7. URN Namespace Definition Template . . . . . . . . . . . . . . 10 6.2. Version . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6.4. Registrant . . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.5. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 6.6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 6.7. Assignment . . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Changes from RFC 3406 . . . . . . . . . . . . . . . . 16 6.8. Resolution . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 6.9. Documentation . . . . . . . . . . . . . . . . . . . . . . 10
7. Registering a URN Namespace . . . . . . . . . . . . . . . . . 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 RFC 3406 . . . . . . . . . . . . . . . . 13
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 13
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 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 the specification [I-D.ietf-urnbis-rfc2141bis-urn] by defining:
following:
o The concept of a URN namespace. o The concept of a URN namespace.
o A mechanism for defining URN namespaces and associating each
namespace with a public identifier (called a Namespace ID or o A mechanism for defining a URN namespace and associating it with a
"NID"). public identifier (called a Namespace ID or "NID").
o Procedures for registering namespace identifiers with the Internet
Assigned Numbers Authority (IANA). o Procedures for registering NIDs with the Internet Assigned Numbers
Authority (IANA).
Syntactically, the NID follows the 'urn' scheme name. For instance,
a URN in the 'example' namespace [RFC6963] might be of the form
"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
valid URN, because a URN needs to be assigned according to the valid URN, because a URN needs to be assigned according to the
rules of a particular namespace (in terms of syntax, semantics, rules of a particular namespace (in terms of syntax, semantics,
and process). and process).
skipping to change at page 3, line 41 skipping to change at page 3, line 45
A string in the namespace identifier slot of the URN syntax is A string in the namespace identifier slot of the URN syntax is
not necessarily a valid URN namespace identifier, because in not necessarily a valid URN namespace identifier, because in
order to be valid a namespace needs to be defined and registered order to be valid a namespace needs to be defined and registered
in accordance with the rules of this document. in accordance with the rules of this document.
URN namespaces were originally defined in [RFC2611], which was URN namespaces were originally defined in [RFC2611], which was
obsoleted by [RFC3406]. Based on experience with defining and obsoleted by [RFC3406]. Based on experience with defining and
registering URN namespaces since that time, this document specifies registering URN namespaces since that time, this document specifies
URN namespaces with the smallest reasonable set of changes from URN namespaces with the smallest reasonable set of changes from
[RFC3406]. This document obsoletes RFC 3406. [RFC3406], while at the same time simplifying the registration
process. This document obsoletes RFC 3406.
2. Terminology 2. Terminology
Several important terms used in this document are defined in the URN Several important terms used in this document are defined in the URN
syntax specification [I-D.ietf-urnbis-rfc2141bis-urn]. syntax specification [I-D.ietf-urnbis-rfc2141bis-urn].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. What is a URN Namespace? 3. What is a URN Namespace?
For the purposes of URNs, a "namespace" is a collection of unique A URN namespace is a collection of identifiers that are (1) unique,
identifiers that are consistently assigned according to a common (2) assigned in a consistent way, and (3) assigned according to a
definition. 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 1. The "uniqueness" constraint means that an identifier within the
the namespace is assigned by an organization or in accordance with a namespace is never assigned to more than one resource and never
process that is always followed (e.g., in the form of an algorithm). reassigned to a different resource.
The common definition constraint means that both the syntax for 2. The "consistent assignment" constraint means that an identifier
identifiers within the namespace and the process for assigning such within the namespace is assigned by an organization or minted in
identifiers are clearly defined in a specification. accordance with a process or algorithm that is always followed.
A URN namespace is identified by a particular designator (which 3. The "common definition" constraint means that there are clear
syntactically follows the 'urn' scheme name) in order to: definitions for the syntax of identifiers within the namespace
and the process of assigning or minting them.
o Ensure the global uniqueness of URNs. A URN namespace is identified by a particular NID in order to ensure
o Optionally provide a cue regarding the structure of URNs assigned the global uniqueness of URNs and, optionally, to provide a cue
within a namespace. regarding the structure of URNs assigned within a namespace.
With regard to global uniqueness, using different designators for With regard to global uniqueness, using different NIDs for different
different collections of identifiers ensures that no two URNs will be collections of identifiers ensures that no two URNs will be the same
the same for different resources (since each collection is required for different resources, since each collection is required to
to uniquely assign each identifier). For instance, some identifier uniquely assign each identifier. However, a single resource can have
systems use strings of numbers as identifiers (e.g., ISBN, ISSN, more than one URN assigned to it for different purposes (e.g., some
phone numbers). It is conceivable that some numbers might be valid numbers might be valid identifiers in two different identifier
identifiers in two different established identifier systems, where systems, where the namespace identifier differentiates between the
the namespace identifier differentiates between the resulting URNs. resulting URNs).
With regard to the structure of URNs assigned within a namespace, the With regard to the structure of URNs assigned within a namespace, the
development of an identifier structure, and thereby a collection of development of an identifier structure (and thereby a collection of
identifiers, is a process that is inherently dependent on the identifiers) depends on the requirements of the community defining
requirements of the community defining the identifiers, how they will the identifiers, how the identifiers will be assigned and used, etc.
be assigned, and the uses to which they will be put. All of these These issues are beyond the scope of URN syntax and the general rules
issues are specific to the individual community seeking to define a for URN namespaces, because they are specific to the community
namespace (e.g., a publishing community, an association of defining a namespace (e.g., the bibliographic and publishing
booksellers, developers of particular application protocols, etc.); communities in the case of the 'ISBN' and 'ISSN' namespaces, or the
therefore these issues are beyond the scope of URN syntax and the developers of extensions to the Extensible Messaging and Presence
rules regarding URN namespaces in general. Protocol in the case of the 'XMPP' namespace).
URN namespaces inherit certain rights and responsibilities, URN namespaces inherit certain rights and responsibilities, e.g.:
including:
o They uphold the general principles of a well-managed URN namespace o They uphold the general principles of a well-managed URN namespace
by providing persistent identification of resources and unique by providing persistent identification of resources and unique
assignment of identifier strings. assignment of identifier strings.
o They can be registered in global registration services. o 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
necessary to define the namespace, and the procedures for needed to define the namespace, and the procedures for registration.
registration. To date, the vast majority of the registered Because the majority of the namespaces registered so far have been
namespaces have been formal, so this document concentrates on formal formal, this document concentrates on formal namespaces.
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 can be requested, and IETF review sought, in cases A formal namespace provides benefit to some subset of users on the
where the publication of the NID proposal and the underlying Internet (i.e., not limited to users in communities or networks not
namespace will provide benefit to some subset of users on the connected to the Internet). For example, it would be inappropriate
Internet. That is, a formal NID proposal, if accepted, needs to be for a NID to effectively force someone to use a proprietary network
functional on and with the global Internet, not limited to users in or service not open to the general Internet user. The intent is
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 a proprietary network
or service that was not at all open to the general Internet user,
then it would make a poor request for a formal NID. The intent is
that, while the community of those who might actively use the names that, while the community of those who might actively use the names
assigned within that NID might be small (but no less important), the assigned within that NID might be small, the potential use of
potential use of names within that NID is open to any user on the identifiers within that NID is open to any user on the Internet.
Internet. Formal NIDs might be appropriate when some aspects are not fully
open. For example, a namespace might make use of a fee-based,
It is expected that formal NIDs might be applied to namespaces where privately managed, or proprietary registry for assignment of URNs in
some aspects are not fully open. For example, a namespace might make the namespace. However, it might still benefit some Internet users
use of a fee-based, privately managed, or proprietary registry for if the associated services have openly-published access protocols.
assignment of URNs in the namespace. However, it might still provide
benefit to some Internet users if the services associated have
openly-published access protocols.
In addition to the basic information specified in the namespace
definition template (see Section 7), a formal namespace request needs
to be accompanied by documented considerations of the need for a new
namespace and of the community benefit from formally establishing the
proposed URN namespace.
Additionally, since the goal of URNs is to provide persistent
identification, a formal namespace request needs to give some
consideration as to the longevity and maintainability of the
namespace. Possible factors to consider with regard to an
organization that will assign URNs within a namespace include the
following:
o It ought to demonstrate stability and the ability to maintain the
URN namespace for a long time; absent such evidence, it ought to
be clear how the namespace can remain viable if the organization
can no longer maintain the namespace.
o It ought to demonstrate competency in name assignment. This will
improve the likelihood of persistence (e.g. to minimize the
likelihood of conflicts).
o It ought to commit to not re-assigning existing names and to
allowing old names to continue to be valid, even if the owners or
assignees of those names are no longer members or customers of
that organization. With regard to URN resolution, 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.
4.2. Informal Namespaces
Informal namespaces are full-fledged URN namespaces, with all the
rights and responsibilities associated thereto. Informal namespaces
differ from formal namespaces in the process for 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
A URN namespace is defined by the following factors:
o The syntax of URNs assigned within the namespace, in conformance
with the fundamental URN syntax [I-D.ietf-urnbis-rfc2141bis-urn].
o The process for assigning URNs within the namespace.
o Optionally, the process for resolving URNs issued within the
namepace.
Processes for resolution of URNs assigned within a namespace (if any)
are out of scope for this document. The following sections provide
guidelines for (1) defining the syntax of URNs within a namespace and
(2) specifying how URNs will be assigned within a namespace.
5.1. Formal Namespaces An organization that will assign URNs within a formal namespace ought
to meet the following criteria:
Formal NIDs are assigned as a result of IETF Review as defined in the o Organizational stability and the ability to maintain the URN
"IANA Considerations" document [RFC5226]. Thus an application for a namespace for a long time; absent such evidence, it ought to be
formal NID is made by publishing an RFC in the IETF stream, either as clear how the namespace can remain viable if the organization can
the product of an IETF working group or as an individual submission no longer maintain the namespace.
sponsored by an Area Director. The RFC need not be standards track o Competency in name assignment. This will improve the likelihood
(indeed, to date most RFCs registering URN namespaces have been of persistence (e.g. to minimize the likelihood of conflicts).
informational), but it will be subject to IESG review and approval
pursuant to the guidelines provided here (as well as standard RFC
publication guidelines).
5.1.1. Syntax o Commitment to not reassigning existing names and to allowing old
names to continue to be valid, even if the owners or assignees of
those names are no longer members or customers of that
organization. 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 registration requests a particular NID, subject to A formal namespace establishes a particular NID, subject to the
the following constraints (above and beyond the syntax rules following constraints (above and beyond the syntax rules specified in
specified in [I-D.ietf-urnbis-rfc2141bis-urn]): [I-D.ietf-urnbis-rfc2141bis-urn]):
o It MUST NOT be an already-registered NID. o It MUST NOT be an already-registered NID.
o It MUST NOT start with "urn-" (which is reserved for informal o It MUST NOT start with "urn-" (which is reserved for informal
namespaces). namespaces).
o It MUST be more than two characters long. o It MUST be more than two characters long.
o It MUST NOT start with "XY-", where "XY" is any combination of two o It MUST NOT start with "XY-", where "XY" is any combination of two
ASCII letters. 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.
5.1.2. Specification 4.2. Informal Namespaces
The specification defining a formal namespace MUST include a
completed namespace definition template (see Section 7).
The specification also MUST include the following sections.
First, the "Namespace Considerations" section outlines the perceived
need for a new namespace (e.g., by describing where existing
namespaces fall short of the proposer's requirements). Potential
considerations include:
o The type of resources to be identified
o The type of services to be supported
o Procedures for assigning URNs within this namespace
o Processes for resolving URNs assigned within this namespace, if
any
It is expected that more than one namespace might serve the same
"functional" purpose; the intent of the "Namespace Considerations"
section is to provide a record of the proposer's "due diligence" in
exploring existing possibilities, for the consideration by the
Internet community, expert reviewers, and the IESG.
Second, the "Community Considerations" section explains how the
intended community will benefit by assignment of this namespace, as
well as how a general Internet user will be able to use the space if
they care to do so. Potential considerations include:
o Methods and benefits for using the assigned URNs
o Methods and benefits for resolving the assigned URNs (if any)
o The kinds of software applications that can use or resolve the
assigned URNs (e.g., by differentiating among disparate
namespaces, identifying resources in a persistent fashion, or
meaningfully resolving and accessing services associated with the
namespace)
Third, the "Security Considerations" section describes any potential
security-related issues with regard to 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 lexical equivalence (see also
[RFC6943]), leakage of private information when identifiers are
communicated on the public Internet, the potential for directory
harvesting, and the issues discussed in [RFC3552].
Fourth, the "IANA Considerations" section indicates that the document
includes a URN NID registration that is to be entered into the IANA
registry of URN NIDs.
5.2. Informal Namespaces
Informal namespaces are directly requested of IANA and are assigned
based on a policy of First Come First Served [RFC5226].
The namespace identifier assigned by IANA has the following syntax: Informal namespaces are full-fledged URN namespaces, with all the
associated rights and responsibilities. Informal namespaces differ
from formal namespaces in the process for assigning a NID: IANA will
assign an alphanumeric NID (e.g., "urn-7") to informal namespaces,
with the following syntax:
"urn-" <number> "urn-" <number>
The <number> is chosen by IANA. The only restrictions on <number> The only restrictions on <number> are that it (1) consist strictly of
are that it (1) consist strictly of ASCII digits and (2) not cause ASCII digits and (2) not cause the NID to exceed the length
the NID to exceed the length limitations defined in the URN syntax limitations defined in the URN syntax specification
specification [I-D.ietf-urnbis-rfc2141bis-urn]. [I-D.ietf-urnbis-rfc2141bis-urn].
6. Registering a URN Namespace
6.1. Formal Namespaces
The registration policy for formal namespaces is IETF Review
[RFC5226]. The key steps for registration of a formal namespace are:
1. Submit an Internet-Draft that includes all of the information
described under Section 5.1.2 and Section 7 of this document.
2. Send the completed namespace definition template, along with a
pointer to the Internet-Draft, to the urn-nid@ietf.org discussion
list for technical review.
3. If necessary to address comments received, repeat steps 1 and 2.
4. Ask the responsible Area Director to process the Internet-Draft
for publication as an RFC. Note that the IESG can request
further changes or direct discussion to designated working
groups, area experts, etc.
5. If the IESG approves the document for publication as an RFC, the
IANA will register the requested NID.
A registration can be revised by updating the RFC through normal IETF 5. Defining a URN Namespace
processes [RFC2606]. The authors of the revised document need to
follow the same steps outlined above for new registrations.
6.2. Informal Namespaces The definition of a formal namespace ought to pay particular
attention to:
The registration policy for informal namespaces is First Come First o The purpose of the namespace.
Served [RFC5226]. The key steps for registration of an informal o The syntax of URNs assigned within the namespace.
namespace are: o The process for assigning URNs within the namespace.
o The security implications of assigning and using the assigned
URNs.
o Optionally, the process for resolving URNs issued within the
namepace.
1. Write a completed namespace definition template (see Section 7). The following sections explain these matters in greater detail. For
This can be done as part of an Internet-Draft. convenience, a template for defining and registering a URN namespace
2. Send the completed template to the urn-nid@ietf.org discussion is provided under Section 6. This information can be especially
list for technical review. helpful to entities that wish to request assignment of a URN in a
3. If necessary to address comments received, repeat steps 1 and 2. namespace and to entities that wish to provide URN resolution for a
4. Once comments have been addressed and the review period has namespace.
expired, send a registration request to IANA (via the
iana@iana.org email address) with the final template.
Informal namespaces can also be revised by updating the template and 5.1. Purpose
processing it as outlined above for new registrations.
7. URN Namespace Definition Template The "Purpose" section of the template describes matters such as:
Definition of a URN namespace is accomplished by completing the o The kinds of resources identified by URNs assigned within the
following template. In addition to providing a mechanism for namespace.
defining 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 o Why it is preferable to use URNs rather than some other technology
applicable) (e.g., URIs) and why existing URN namespace (if any) are not a
o entities seeking to provide URN resolvers for a namespace (if good fit.
applicable)
Providing a complete and accurate template is particularly helpful to o The kinds of software applications that can use or resolve the
communities that are evaluating the possibility of using a portion of assigned URNs (e.g., by differentiating among disparate
an existing URN namespace rather than creating a new namespace. namespaces, identifying resources in a persistent fashion, or
meaningfully resolving and accessing services associated with the
namespace).
As described under Section 5.1.2, applications for formal URN o The scope of the namespace (public vs. private, global vs. local
namespaces MUST also document the "Namespace Considerations", to a particular organization, nation, or industry). For example,
"Community Considerations", "Security Considerations", and "IANA a namespace claiming to deal in "social security numbers" ought to
Considerations". have a global scope and address all social security number
structures, whereas a URN scheme for a particular national system
would need to handle only that nation's social security numbers.
The information to be provided in the template is as follows: o How the intended community (and the Internet community at large)
will benefit from using or resolving the assigned URNs.
Namespace ID: 5.2. Syntax
Requested of IANA (formal) or assigned by IANA (informal). The "Syntax" section of the template describes:
Registration Information: o A description of the structure of URNs within the namespace, in
conformance with the fundamental URN syntax
[I-D.ietf-urnbis-rfc2141bis-urn]. The structure might be
described in terms of a formal definition (e.g., using Augmented
BNF for Syntax Specifications (ABNF) as specified in [RFC5234]),
an algorithm for generating conformant URNs, a regular expression
for parsing the identifier into components, or by explaining that
the structure is opaque.
The version and date of the registration: o Any special character encoding rules for assigned URNs (e.g.,
which character ought to always be used for single-quotes).
- Registration version number: starting with 1, o Rules for determining equivalence between two identifiers in the
incrementing by 1 with each new version namespace. Such rules ought to always have the effect of
- Registration date: date submitted to the IANA, using the eliminating false negatives that might otherwise result from
format YYYY-MM-DD comparison. If it is appropriate and helpful, reference can be
made to the equivalence rules defined in the 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 identifier string, or between single-quotes and double-
quotes. (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 to this
specific namespace only.)
Declared registrant of the namespace: o Any special considerations necessary for conforming with the URN
syntax. This is particularly applicable in the case of legacy
naming systems that are used in the context of URNs. For example,
if a namespace is used in contexts other than URNs, it might make
use of characters that are reserved in the URN syntax. This
section ought to note any such characters, and outline necessary
mappings to conform to URN syntax. Normally, this will be handled
by percent-encoding the character as specified in the URI
specification [RFC3986].
This includes: 5.3. Assignment
- Registering organization The "Assignment" section of the template describes matters such as:
Name
Address
- Designated contact person
Name
Contact information
(at least one of email address,
phone number, postal address)
Declaration of syntactic structure: o Mechanisms or authorities for assigning URNs to resources. It
ought to make clear whether assignment is completely open (e.g.,
following a particular algorithm), completely closed (e.g., for a
private organization), or limited in various ways (e.g., delegated
to authorities recognized by a particular organization); if
limited, it ought to explain how to become an assigner of
identifiers or how to request assignemtn of identifers from
existing assignment authorities.
This section ought to outline any structural features of o Methods for ensuring that URNs within the namespace are unique.
identifiers in this namespace. At the very least, this For example, identifiers might be assigned sequentially or in
description can be used to introduce terminology used in accordance with some well-defined process by a single authority,
other sections. This structure can also be used for assignment might be partitioned among delegated authorities that
determining realistic caching/shortcuts approaches; are individually responsible for respecting uniqueness rules, or
suitable caveats ought to be provided. If there are any URNs might be minted independently following an algorithm that
specific character encoding rules (e.g., which character itself guarantees uniqueness.
ought to always be used for single-quotes), these ought
to be listed here. If the namespace allows use of the
URI query component, URI fragment identifier component,
or both, such usage needs to be described here (in
addition to any other namespace-specific syntax, such
as distinguishers for integral parts of resources
identified by URNs within the namespace).
At a high level, answers might include, but are not limited to: o Methods for ensuring the longevity and maintainability of the
namespace and URNs assigned with the namespace. Although non-
reassignment of URNs ensures that a URN will persist in
identifying a particular resource even after the "lifetime of the
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.
- A formal definition of the structure, e.g., in terms 5.4. Security
of Augmented BNF for Syntax Specifications (ABNF) as
specified in [RFC5234]
- A regular expression for parsing the identifier into
components, including naming authorities
- An algorithm for generating conformant URNs
- An explanation that the structure is opaque
Relevant ancillary documentation: The "Security" section of the template describes any potential
security-related issues with regard to 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 are
communicated on the public Internet, the potential for directory
harvesting, and various issues discussed in the guidelines for
security considerations in RFCs [RFC3552].
This section ought to list any RFCs, specifications, or 5.5. Resolution
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: The "Resolution" section specifies the rules for resolution of URNs
assigned within the namespace. If such URNs are intended to be
resolvable, the namespace needs to be registered in a Resolution
Discovery System (RDS, see [RFC2276]) such as DDDS. Resolution then
proceeds according to standard URI resolution processes, as well as
the mechanisms of the RDS. This section ought to lists the
requirements for becoming a recognized resolver of URNs in the
relevant namespace (and being so listed in the RDS registry).
Answers might include, but are not limited to:
- Pointers to specifications that define the syntax and o The namespace is not listed with an RDS; therefore this section is
semantics of the namespace not applicable.
- Mention of documentation that describes the processes o Resolution mirroring is completely open, with a mechanism for
followed by an organization that assigns URNs in the updating an appropriate RDS.
namespace o Resolution is controlled by entities to which assignment has been
- Explanatory material describing the namespace delegated.
Identifier uniqueness considerations: 6. Registration Template
This section ought to address the requirement that URNs are 6.1. Namespace ID
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 Requested of IANA (formal) or assigned by IANA (informal).
example, information on "Today's Weather" might be considered
a single resource, although the content is dynamic.)
At a high level, answers might include, but are not limited to: 6.2. Version
- Exposition of the structure of the identifiers, and The version of the registration, starting with 1 and incrementing by
partitioning of the space of identifiers amongst assignment 1 with each new version.
authorities which are individually responsible for
respecting uniqueness rules
- Description of a method for assignment of identifiers (e.g.,
identifiers are assigned sequentially)
- An explanation that this information is withheld (i.e.,
the namespace is opaque)
Identifier persistence considerations: 6.3. Date
Although non-reassignment of URN identifiers ensures that a URN The date when the registration is requested of IANA, using the format
will persist in identifying a particular resource even after YYYY-MM-DD.
the "lifetime of the resource", 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: 6.4. Registrant
- Quality of service considerations The person or organization that has registered the NID, including the
following information:
Process of identifier assignment: 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.
This section ought to detail the mechanisms and/or authorities 6.5. Purpose
for assigning URNs to resources. It ought to make clear whether
assignment is completely open or, if limited, how to become an
assigner of identifiers or how to get an identifer assigned by
existing assignment authorities.
At a high level, answers could include, but are not limited to: Described under Section 5.1 of this document.
- Assignment is completely open, following a particular 6.6. Syntax
algorithm
- Assignment is delegated to authorities recognized by a
particular organization (e.g., the Digital Object Identifier
Foundation controls the DOI assignment space and its
delegation)
- Assignment is completely closed (e.g., for a private
organization)
Process for identifier resolution: Described under Section 5.2 of this document.
If a namespace is intended to be accessible for global 6.7. Assignment
resolution, it needs to be registered in an RDS (Resolution
Discovery System, see [RFC 2276]) such as DDDS. Resolution
then proceeds according to standard URI resolution processes,
and the mechanisms of the RDS. What this section ought to
outline is the requirements for becoming a recognized resolver
of URNs in this namespace (and being so listed in the RDS
registry).
At a high level, answers might include, but are not limited to: Described under Section 5.3 of this document.
- The namespace is not listed with an RDS; therefore this 6.8. Resolution
section is not applicable
- Resolution mirroring is completely open, with a mechanism
for updating an appropriate RDS
- Resolution is controlled by entities to which assignment has
been delegated
Rules for lexical equivalence: Described under Section 5.5 of this document.
If there are particular algorithms for determining equivalence 6.9. Documentation
between two identifiers in the underlying namespace (hence, in
the URN string itself), rules can be provided here. Such rules
ought to always have the effect of eliminating false negatives
that might otherwise result from comparison.
If it is appropriate and helpful to do so, reference can be Any Internet-Draft, RFC, specification, or other published document
made to the equivalence rules defined in the URI specification that defines or explains the namespace.
[RFC3986].
Some examples include: 7. Registering a URN Namespace
- Equivalence between uppercase and lowercase characters in 7.1. Formal Namespaces
the Namespace Specific String
- Equivalence between hyphenated and non-hyphenated groupings
in the identifier string
- Equivalence between single-quotes and double-quotes
- Namespace-defined equivalences between specific characters,
such as "character X with or without diacritic marks".
Note that these are not normative statements for any kind of The registration policy for formal namespaces is Expert Review as
best practice related to handling of equivalences between defined in the "IANA Considerations" document [RFC5226]. The key
characters in general; they are statements limited in scope to steps for registration of a formal namespace are:
reflecting the rules for this specific namespace only.
Conformance with URN syntax: 1. Fill out the namespace registration template (see Section 6).
This can be done as part of an Internet-Draft or a specification
in another series, although that is not necessary.
2. Send the completed template to 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 designated experts approve the request, the IANA will
register the requested NID.
This section ought to outline any special considerations A formal namespace registration can be revised by updating the
necessary for conforming with the URN syntax. This is registration template, following the same steps outlined above for
particularly applicable in the case of legacy naming new registrations.
systems that are used in the context of URNs.
For example, if a namespace is used in contexts other than URNs, 7.2. Informal Namespaces
it might make use of characters that are reserved in the URN
syntax.
This section ought to flag any such characters, and outline The registration policy for informal namespaces is First Come First
necessary mappings to conform to URN syntax. Normally, this Served [RFC5226]. The key steps for registration of an informal
will be handled by percent-encoding the character as specified namespace are:
in the URI specification [RFC3986].
Validation mechanism: 1. Write a completed namespace definition template (see Section 6).
2. Send it to the urn-nid@ietf.org discussion list for feedback.
3. Once the review period has expired, send the final template to
IANA (via the iana@iana.org email address).
Apart from attempting resolution of a URN, a URN namespace may An informal namespace registration can be revised by updating the
provide mechanisms for "validating" a URN -- i.e., determining registration template, following the same steps outlined above for
whether a given string is currently a validly-assigned URN. new registrations.
There are two issues here: 1) users ought not "guess" URNs in
a namespace; 2) when the URN namespace is based on an existing
identifier system, it might not be the case that all existing
identifiers are assigned on Day 0. The reasonable expectation
is that the resource associated with each resulting URN is
somehow related to the thing identified by the original
identifier system, but those resources might not exist for each
original identifier. For example, even if a URN namespace were
defined based on telephone numbers, it is not clear that all
telephone numbers would immediately become "valid" URNs
resolvable using whatever mechanisms are described as part of
the namespace registration.
Validation mechanisms might be: 8. Guidelines for Designated Experts
- A syntax grammar Experience to date with NID registration requests has shown that
- An online service registrants sometimes do not initially understand some of the
- An offline service subtleties of URN namespaces, and that defining the namespace in the
form of a specification enables the registrants to clearly formulate
their "contract" with the intended user community. Therefore,
although the registration policy for formal namespaces is Expert
Review and a specification is not required, the designated experts
for NID registration requests are encouraged to prefer that a
specification exist documenting the namespace definition.
Scope: 9. IANA Considerations
This section ought to outline the scope of the use of the This document outlines the processes for registering URN namespaces,
identifiers in this namespace. Apart from considerations of and has implications for the IANA in terms of registries to be
private vs. public namespaces, this section is critical in maintained. In all cases, the IANA ought to assign the appropriate
evaluating the applicability of a requested NID. For example, NID (formal or informal) once the procedures outlined in this
a namespace claiming to deal in "social security numbers" document have been completed.
ought to have a global scope and address all social security
number structures (unlikely). On the other hand, at a national
level, it is reasonable to propose a URN namespace for "this
nation's social security numbers".
8. Security Considerations 10. Security Considerations
This document largely focuses on providing mechanisms for the This document largely focuses on providing mechanisms for the
declaration of public information. Nominally, these declarations declaration of public information. Nominally, these declarations
will be of relatively low security profile, however there is always will be of relatively low security profile, however there is always
the danger of "spoofing" and providing misinformation. Information the danger of "spoofing" and providing misinformation. Information
in these declarations ought to be taken as advisory. in these declarations ought to be taken as advisory.
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; see Section 5.1.2 for further identifiers within the namespace.
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. References 11. References
10.1. Normative References 11.1. Normative References
[I-D.ietf-urnbis-rfc2141bis-urn] [I-D.ietf-urnbis-rfc2141bis-urn]
Saint-Andre, P. and R. Moats, "Uniform Resource Name (URN) Saint-Andre, P., "Uniform Resource Name (URN) Syntax",
Syntax", draft-ietf-urnbis-rfc2141bis-urn-05 (work in draft-ietf-urnbis-rfc2141bis-urn-06 (work in progress),
progress), July 2013. August 2013.
[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,
May 2008. May 2008.
10.2. Informative References 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 [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource
Name Resolution", RFC 2276, January 1998. Name Resolution", RFC 2276, January 1998.
[RFC2611] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, [RFC2611] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"URN Namespace Definition Mechanisms", BCP 33, RFC 2611, "URN Namespace Definition Mechanisms", BCP 33, RFC 2611,
June 1999. June 1999.
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition "Uniform Resource Names (URN) Namespace Definition
skipping to change at page 16, line 35 skipping to change at page 13, line 25
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in "Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, June 2012. Application Protocols", BCP 178, RFC 6648, June 2012.
[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
for Examples", BCP 183, RFC 6963, May 2013.
Appendix A. Changes from RFC 3406 Appendix A. Changes from RFC 3406
Although on the surface it might appear that this document is This document makes the following substantive changes from [RFC3406]:
significantly different from [RFC3406], in general it only modifies
the order of presentation, with the intent of making it easier for o Relaxes the registration policy for formal namespaces from "IETF
interested parties to define and register URN namespaces. In Review" to "Expert Review" [RFC5226].
addition, some of the text was updated to be consistent with the o Removes the category of experimental namespaces, consistent with
definition of Uniform Resource Identifiers (URIs) [RFC3986] and the [RFC6648].
processes for registering information with the IANA [RFC5226], as o Simplifies the registration template.
In addition, some of the text 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] well as more modern guidance with regard to security issues [RFC3552]
and identifier comparison [RFC6943]. The only major substantive and identifier comparison [RFC6943].
change was removing the category of experimental namespaces,
consistent with [RFC6648].
Authors' Addresses Appendix B. Contributors
Peter Saint-Andre (editor) RFC 3406, which provided the 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
Cisco Systems, Inc. Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600 1899 Wynkoop Street, Suite 600
Denver, CO 80202 Denver, CO 80202
USA USA
Phone: +1-303-308-3282 Phone: +1-303-308-3282
Email: psaintan@cisco.com Email: psaintan@cisco.com
Leslie Daigle
Thinking Cat Enterprises
Dirk-Willem van Gulik
WebWeaving
Renato Iannella
Semantic Identity
Patrick Faltstrom
Netnod
 End of changes. 98 change blocks. 
477 lines changed or deleted 348 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/