draft-ietf-urnbis-rfc3406bis-urn-ns-reg-03.txt   draft-ietf-urnbis-rfc3406bis-urn-ns-reg-04.txt 
IETF URNbis WG A. Hoenes, Ed. URNBIS P. Saint-Andre, Ed.
Internet-Draft TR-Sys Internet-Draft Cisco Systems, Inc.
Obsoletes: 3406 (if approved) October 19, 2012 Obsoletes: 3406 (if approved) L. Daigle
Intended status: BCP Intended status: BCP D. van Gulik
Expires: April 22, 2013 Expires: May 31, 2013 R. Iannella
P. Faltstrom
November 27, 2012
Defining Uniform Resource Name (URN) Namespaces Uniform Resource Name (URN) Namespace Definitions
draft-ietf-urnbis-rfc3406bis-urn-ns-reg-03 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-04
Abstract Abstract
RFC 2141bis formalizes the concept of Uniform Resource Names (URNs) This document supplements the Uniform Resource Name (URN) syntax
for persistent, location-independent, resource identifiers within the specification by defining the concept of a URN namespace, as well as
generic URI system specified in RFC 3986. To structure and organize mechanisms for defining and registering such namespaces. This
URN usage, RFC 2141bis specifies a hierarchy that divides the set of document obsoletes RFC 3406.
possible URNs into "URN Namespaces" that can be individually defined
and managed. URN Namespaces allow to map existing identifier systems
into the URN scheme and thereby make available generic, network-based
resolution services for the identified resources (documents,
artifacts, and other objects) and metadata related to them.
To this end, URN Namespaces need to be defined and specified in a
comparable manner, and their Namespace Identifiers (NIDs) need to be
registered with IANA, so that naming conflicts are avoided and
implementers of services can follow a structured approach in support
of various namespaces, guided by the registry to the related
documents and the particularities of specific namespaces, as
described in these Namespace registration documents.
This RFC serves as a design guideline for stakeholders of URN
Namespaces and authors of URN Namespace definition and registration
documents. It describes the process to be followed to register a URN
Namespace with IANA and the essential content of such documents.
This document supersedes and replaces RFC 3406.
Discussion
Discussion of this memo utilizes the urn@ietf.org mailing list.
[[ RFC-Editor: this clause to be deleted before RFC publication ]]
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 22, 2013. This Internet-Draft will expire on May 31, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 3, line 7 skipping to change at page 2, line 21
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirement Language and Terminology . . . . . . . . . . . 5 2. Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 4
2. What is a URN Namespace? . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. URN Namespace (Registration) Types . . . . . . . . . . . . . . 8 4. What is a URN Namespace? . . . . . . . . . . . . . . . . . . . 4
3.1. Experimental Namespaces . . . . . . . . . . . . . . . . . 8 5. URN Namespace Types . . . . . . . . . . . . . . . . . . . . . 5
3.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 8 5.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 5
3.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 8 5.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 6
4. URN Namespace Registry: Processes for Registration and 6. Defining a URN Namespace . . . . . . . . . . . . . . . . . . . 7
Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 7
4.1. Experimental Namespaces: No Registration . . . . . . . . . 11 6.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 12 6.1.2. Specification . . . . . . . . . . . . . . . . . . . . 8
4.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 13 6.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 8
4.4. Registration Documents . . . . . . . . . . . . . . . . . . 14 7. Registering a URN Namespace . . . . . . . . . . . . . . . . . 9
4.4.1. Namespace Considerations in Registration Documents . . 14 7.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 9
4.4.2. Community Considerations in Registration Documents . . 15 7.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 9
4.4.3. Security Considerations in Registration Documents . . 16 8. URN Namespace Definition Template . . . . . . . . . . . . . . 10
4.4.4. IANA Considerations in Registration Documents . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 Appendix A. Changes from RFC 3406 . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. URN Namespace Definition Template . . . . . . . . . . 21
A.1. Annotated URN Namespace Definition Template . . . . . . . 21
A.2. Plain URN Namespace Definition Template (Informative) . . 27
Appendix B. Summary of Registration Steps (Informative) . . . . . 28
Appendix C. Changes from RFC 3406 (Informative) . . . . . . . . . 29
C.1. Essential Changes since RFC 3406 . . . . . . . . . . . . . 29
C.2. Changes from RFC 3406 to URNbis WG Draft -00 . . . . . . . 29
C.3. Changes from URNbis WG I-D -00 to -01 . . . . . . . . . . 32
C.4. Changes from URNbis WG I-D -01 to -02 . . . . . . . . . . 32
C.5. Changes from URNbis WG I-D -02 to -03 . . . . . . . . . . 32
1. Introduction 1. Introduction
Uniform Resource Names (URNs) are identifiers bound to resources with A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI)
the objective to provide location-independent identification of these that is intended to serve as a persistent, location-independent
resources as well as longevity of reference. URNs are part of the resource identifier. The general class of URNs is differentiated
larger Uniform Resource Identifier (URI) family (see the joint W3C/ from all other URIs through the use of the 'urn' URI scheme.
IETF memorandum, RFC 3305 [RFC3305], and the IETF STD 66, RFC 3986
[RFC3986]), with the specific goal of persistent binding names to
resources.
The URN scheme formalized in RFC 2141bis
[I-D.ietf-urnbis-rfc2141bis-urn] structures and organizes the
entirety of URNs into a hierarchy that divides the set of possible
URNs into "URN Namespaces" that can be individually defined, managed,
and (optionally) further subdivided. URN Namespaces in particular
serve to map existing identifier systems into the URN system and
thereby make available generic, network-based resolution services for
the identified resources (documents, artifacts, abstract concepts,
and other objects) and their metadata.
There are two assumptions that are key to this document:
Assumption #1: Assignment of a URN is a managed process.
I.e., not all strings that conform to URN syntax are necessarily
valid URNs. A URN is assigned according to the rules of a
particular namespace (in terms of syntax, semantics, and process).
Assumption #2: The space of URN Namespaces is managed. This document supplements the Uniform Resource Name (URN) syntax
specification by defining (1) the concept of a URN namespace, (2) a
mechanism for defining such namespaces and associating each namespace
with a public identifier (called a Namespace ID or "NID"), and (3)
procedures for registering such namespaces with the Internet Assigned
Numbers Authority (IANA).
I.e., not all syntactically correct URN Namespace identifiers (per This document rests on two key assumptions:
the URN syntax definition) designate valid URN Namespaces. A URN
Namespace must have a well recognized definition in order to be
valid.
To actually draw benefits from this unification (structured embedding 1. Assignment of a URN is a managed process.
of existing namespaces into the URN framework), URN Namespaces have
common design considerations, they need to be specified in a
comparable manner, and their Namespace Identifiers (NIDs) need to be
centrally registered, so that naming conflicts are avoided and
implementers of services can follow a structured approach in support
of various namespaces, guided by the registry to the related
documents and the particularities of specific namespaces, as
described in these URN Namespace registration documents.
The primary purpose of this document is to outline a mechanism for A string that conforms to the URN syntax is not necessarily a
explicit URN Namespace definition, associating it with an identifier valid URN, because a URN needs to be assigned according to the
(called a "Namespace ID", or NID). To this end, this RFC defines the rules of a particular namespace (in terms of syntax, semantics,
requirements for URN NID specification documents and provides a and process).
registration template, which is to be registered with the Internet
Assigned Numbers Authority (IANA) [IANA] in the URN Namespaces
registry maintained at [IANA-URN]. However, to give additional
guidance to prospective stakeholders / designers of URN Namespaces in
fulfiling the requirements for registration, this document also
elaborates on generic considerations and design choices for the
establishment of URN Namespaces.
The URN Namespace definition and registration mechanisms originally 2. The space of URN namespaces is itself managed.
have been specified in BCP 33, RFC 2611 [RFC2611], which has been
obsoleted by BCP 66, RFC 3406 [RFC3406]. Guidelines for documents
prescribing IANA procedures have been revised as well over the years,
and at the time of this writing, BCP 26, RFC 5226 [RFC5226] is the
normative document. This document is a revision of RFC 3406 based on
the revised specification of URNs in RFC 2141bis
[I-D.ietf-urnbis-rfc2141bis-urn] and RFC 5226.
The reader is referred to Section 1.1 of RFC 2141bis A string in the namespace identifier slot of the URN syntax is
[I-D.ietf-urnbis-rfc2141bis-urn] for a more detailed synopsis of the not necessarily a valid URN namespace identifier, because in
history of documents fundamental for URNs. order to be valid a namespace needs to be defined and registered
in accordance with the rules of this document.
Note that this document restricts itself to the description of URN namespaces were originally defined in [RFC2611], which was
processes for the creation of URN Namespaces. If generic obsoleted by [RFC3406]. Based on experience with defining and
"resolution" of any so-created URN identifiers is desired, a separate registering URN namespaces since that time, the goal of this document
process of registration in a global NID directory, such as that is to specify URN namespaces with the smallest reasonable set of
proposed by the DDDS system [RFC3401], is necessary. See [RFC3405] changes from [RFC3406].
for information on obtaining registration in the DDDS global NID
directory. RFC 2141bis establishes an IANA registry for URN
services, such that registration documents can unambiguously identify
such services and discuss their applicability to the particular URN
Namespace.
1.1. Requirement Language and Terminology Although on the surface it might appear that this document is
significantly different from [RFC3406], in general it only modifies
the order of presentation, with the intent of making it easier for
people to define and register URN namespaces. However, the only
major substantive change is removing the category of experimental
namespaces, in accorance with [RFC6648].
When spelled in all-capitals as in this paragraph, the key words If approved, this document will obsolete RFC 3406.
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14 [RFC2119]. In this
document, these key words describe requirements for the process to be
followed and the content to be provided in URN Namespace definition
documents and registration templates.
For the purpose of this document, its subject is spelled "URN 2. Discussion Venue
Namespace" (in headline case), whereas in other context, "namespace"
is spelled in lower case, e.g., to designate a (standard or non-
standard) identifier system on which a URN Namespace is based.
2. What is a URN Namespace? The discussion venue for this document is mailing list of the URNBIS
WG; visit <https://www.ietf.org/mailman/listinfo/urn> for
subscription and archive information.
For the purposes of URNs, a "namespace" is a collection of uniquely- 3. Terminology
assigned identifiers. That is, the identifiers are not ever assigned
to more than one resource. These resources may be stable (e.g., a
doctoral dissertation or an abstract concept of a protocol) or
dynamic (e.g., a continuously evolving web site of a periodical or a
specific protocol parameter registry subject to additions and
maintenance). If the identified resource is a metadata record, such
record may describe several objects (such as two versions of a book)
or a collection of objects (such as a periodical with, say, monthly
issues); in this case, these subordinate objects are not the
identified resources. For each namespace, it must be clear what the
identified resources are; if the namespace is heterogenous in this
respect, the registration and resolution systems must unambiguously
designate the kind of identified resource, for each identifier
assigned in the namespace. Once assigned, URNs are never re-assigned
to a different resource. A single resource, however, may have more
than one URN assigned to it -- within a particular Namespace or among
different Namespaces -- for different purposes, since the Namespaces
are not mutually exclusive.
Such abstract namespace might be defined by some pre-established Several important terms used in this document are defined in the URN
(standard or non-standard) identifier system that can be made syntax specification [I-D.saintandre-urnbis-2141bis].
"network-actionable" by embedding it into the URN framework using a
specific URN Namespace. A URN Namespace itself has an identifier in
order to:
- ensure global uniqueness of URNs,
- (where desired) provide a cue for the structure of the identifier.
For example, many identifier systems use strings of numbers as The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
identifiers (e.g., ISBN, ISSN, phone numbers). It is conceivable "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
that there might be some numbers that are valid identifiers in two "OPTIONAL" in this document are to be interpreted as described in
different established identifier systems. Using different [RFC2119].
designators for the two collections (and making these designators an
intrinsic syntactic part of URNs) ensures that no two URNs will be
the same for different resources (since each collection is required
to uniquely assign each identifier).
The development of an identifier structure, and thereby a collection 4. What is a URN Namespace?
of identifiers, is a process that is inherently dependent on the
requirements of the community defining the identifier, how they will
be assigned, and the uses to which they will be put. All of these
issues are specific to the individual community seeking to define a
namespace (e.g., publishing community, association of booksellers,
protocol developers, technology-specific vendor groups, etc.); they
are beyond the scope of the IETF URN work.
If a namespace contains structured resources, per RFC 2141bis For the purposes of URNs, a "namespace" is a collection of unique
[I-D.ietf-urnbis-rfc2141bis-urn] the designers of a related URN identifiers that are consistently assigned according to a common
Namespace and the implementers of the related resolution systems have definition.
available three options for the Namespace to support identification
and resolution of component resources:
a. A Namespace can choose to assign individual identifiers The uniqueness constraint means that an identifier within the
(Namespace Specific String, NSS) to some or all components of a namespace is never assigned to more than one resource and never re-
structured resource that is also named by the identifier system. assigned to a different resource (however, a single resource can have
This method is independent of the Internet media types the more than one URN assigned to it for different purposes).
resolution system(s) for the Namespace can provide. This is the
preferred method. However, there may be rules for a pre-existing
identifier system (that is going to be made accessible via URNs)
and objectives for the NSS format desired that effectively
prohibit such identifier assignments; in such cases, the
Namespace designers cannot adopt this method.
b. A Namespace can choose to provide a resolution system that The consistent assignment constraint means that an identifier within
interprets the 'component' ("c=") directive that can be the namespace is assigned by an organization or in accordance with a
incorporated in the <query> part of URI references to URNs (see process that is always followed.
[I-D.ietf-urnbis-rfc2141bis-urn]). This way, only the basic
resources are assigned an NSS -- which will simplify the
identifier assignment/registration processes/systems for the
namespace, or even be dictated by existing processes/systems --
and the URN resolvers for the Namespace can make use of
additional information captured from the owners of the individual
resources (in any way that is proper for the namespace). This
method is independent of the Internet media types that will be
used to return the URN resolution results for such Namespace, and
as such allows for stable assigned names yet a flexible, perhaps
evolving choice of media types provided by the resolution
system(s).
c. A Namespace that tightly controls the media types provided by The common definition constraint means that the syntax for
particular resolution services might specify how resolution identifiers within the namespace and the process for assigning such
clients can make use of <fragment> identifiers contained in URI identifiers are clearly defined in a specification.
references to URNs of that Namespace (see
[I-D.ietf-urnbis-rfc2141bis-urn]) to pick a component resource
from the media returned by the URN service. Since per STD 66
[RFC3986] <fragment> identifiers of URIs are evaluated at the
client side in a manner specific to each media type (if
applicable at all), this method depends on the specific
capabilities of the media types used.
Namespaces specified prior to RFC 2141bis are constricted to method A URN namespace is identified by a particular designator (which
a. Future Namespace definitions MUST document the methods applicable syntactically follows the 'urn' scheme name) in order to:
to it and available via its resolvers.
This document outlines the processes by which a collection of o Ensure the global uniqueness of URNs.
identifiers satisfying certain constraints (uniqueness of assignment, o Optionally provide a cue regarding the structure of URNs assigned
etc.) can become a bona fide URN Namespace by obtaining a NID. In a within a namespace.
nutshell, a template for the definition of the Namespace is completed
for deposit with IANA, and a NID is assigned. The details of the
process and possibilities for NID strings are outlined below.
3. URN Namespace (Registration) Types With regard to global uniqueness, using different designators for
different collections of identifiers ensures that no two URNs will be
the same for different resources (since each collection is required
to uniquely assign each identifier). For instance, some identifier
systems use strings of numbers as identifiers (e.g., ISBN, ISSN,
phone numbers). It is conceivable that there might be some numbers
that are valid identifiers in two different established identifier
systems, and the namespace identifier differentiates between the
resulting URNs.
There are three categories (types) of URN Namespaces defined here, With regard to the structure of URNs assigned within a namespace, the
distinguished by expected level of service and required procedures development of an identifier structure, and thereby a collection of
for registration. Registration processes for each of these Namespace identifiers, is a process that is inherently dependent on the
types are given in Section 4. In both this Section and Section 4 requirements of the community defining the identifier, how they will
these categories are ordered by increasing relevance/importance for be assigned, and the uses to which they will be put. All of these
the Internet and, accordingly, increasing strenght of requirements issues are specific to the individual community seeking to define a
for the definition and registration processes. namespace (e.g., a publishing community, an association of
booksellers, developers of particular application protocols, etc.);
therefore these issues are beyond the scope of URN syntax and the
rules regarding URN namespaces in general.
3.1. Experimental Namespaces URN namespaces inherit certain rights and responsibilities,
including:
These are not explicitly registered with IANA. o They uphold the general principles of a well-managed URN namespace
by providing persistent identification of resources and unique
assignment of identifier strings.
o They can be registered in global registration services.
No provision is made for avoiding collision of experimental NIDs; 5. URN Namespace Types
they are intended for use within internal or limited experimental
contexts. However, as described below in Section 4.1, these are
designated by a specific form of the NID to allow differentiation
(without preexisting knowledge of details) from the other URN
Namespace types.
3.2. Informal Namespaces There are two types of URN namespace: formal and informal. These are
distinguished by the expected level of service, the information
required to define the namespace, and the procedures for
registration. To date, the vast majority of the registered
namespaces have been formal, so this document concentrates on formal
namespaces.
These are fully fledged URN Namespaces, with all the rights and Note: [RFC3406] defined a third type of "experimental namespaces:,
requirements associated thereto. Informal Namespaces can be denoted by prefixing the namespace identifier with the string "X-".
registered in global registration services. They are required to Consistent with [RFC6648], this specification removes the
uphold the general principles of a well-managed URN Namespace -- experimental category.
providing persistent identification of resources and unique
assignment of identifier strings. Informal and Formal Namespaces
(described below) differ in the NID assignment. IANA will assign to
registered Informal Namespaces a simply structured, alphanumeric,
ordinal NID (following a pattern defined in Section 4.2 below), per
the process outlined in Section 4.
3.3. Formal Namespaces 5.1. Formal Namespaces
A Formal Namespace may be requested, and IETF review sought, in cases A formal namespace can be requested, and IETF review sought, in cases
where the publication of the NID proposal and the underlying where the publication of the NID proposal and the underlying
namespace will provide benefit to some subset of users on the namespace will provide benefit to some subset of users on the
Internet. That is, a formal NID proposal, if accepted, must be Internet. That is, a formal NID proposal, if accepted, needs to be
functional on and with the global Internet, not limited to users in functional on and with the global Internet, not limited to users in
communities or networks not connected to the Internet. For example, communities or networks not connected to the Internet. For example,
assume a NID is requested that is meant for naming of physics consider a NID that is meant for naming of physics research; if that
research material. If that NID request required that the user use a NID request required that the user use a proprietary network or
proprietary network or service that was not at all open to the service that was not at all open to the general Internet user, then
general Internet user, then it would make a poor request for a formal it would make a poor request for a formal NID. The intent is that,
NID. The intent is that, while the community of those who may while the community of those who may actively use the names assigned
actively use the names assigned within that NID may be small (but no within that NID may be small (but no less important), the potential
less important), the potential use of names within that NID is open use of names within that NID is open to any user on the Internet.
to any user on the Internet.
It is however expected that Formal NIDs may be applied to Namespaces It is expected that formal NIDs may be applied to namespaces where
where some aspects are not fully open. For example, a Namespace may some aspects are not fully open. For example, a namespace might make
make use of a fee-based, privately managed, or proprietary registry use of a fee-based, privately managed, or proprietary registry for
for assignment of URNs in the Namespace, but it may still provide assignment of URNs in the namespace. However, it may still provide
benefit to some Internet users if the services associated with it benefit to some Internet users if the services associated have
have openly published access protocols. openly- published access protocols.
In addition to the basic registration information defined in the In addition to the basic information specified in the namespace
registration template (in Appendix A), a Formal Namespace request definition template (see Section 8), a formal namespace request needs
must be accompanied by documented considerations of the need for a to be accompanied by documented considerations of the need for a new
new Namespace and of the benefit for the Internet community from namespace and of the community benefit from formally establishing the
formally establishing the proposed URN Namespace -- see Sections proposed URN namespace.
4.4.1 and 4.4.2 below.
Additionally, since the goal of URNs is to provide persistent Additionally, since the goal of URNs is to provide persistent
identification, careful consideration must be given to the longevity identification, a formal namespace request needs to give some
and maintainability of the URN Namespace. The collective experience consideration as to the longevity and maintainability of the
of the IETF community contains a wealth of information on technical namespace. Possible factors to consider with regard to an
factors that will prevent longevity of identification. Thus, the organization that will assign URNs within a namespace include the
IESG may elect not to accept a proposed Namespace registration if the following:
IETF community consensus is that the registration document contains
technical flaws that will prevent (or seriously impair the
possibility of) persistent identification, and that it therefore
should not be published as an RFC.
In addition to the technical aspects of the Namespace and its
resolution, consideration should be given to the following
organizatorial aspects:
- the organization maintaining the URN Namespace should credibly
demonstrate stability and the ability to maintain the URN
Namespace for a long time, and/or it should be clear how the
Namespace can continue to be usable/useful if the organization
ceases to be able to foster it;
- the organization(s) assigning URNs within the URN Namespace should o It ought to demonstrate stability and the ability to maintain the
demonstrate ability and competency in name assignment; this should URN namespace for a long time; absent such evidence, it ought to
improve the likelihood of persistence (e.g., to minimize the 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); 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.
- the organization(s) assigning URNs within the URN Namespace need 5.2. Informal Namespaces
to be committed to honor the scope, rules, and regulations
outlined in its registration document and the documents defining
the underlying namespace and covering its identifier assignment
and maintenance procedures (if any), and the organization
maintaining the URN Namespace needs to have procedures in force
that aim at ensuring this adherance at a very high confidence
level; and
- the involved organization(s) need to commit to not re-assign
existing names; old names MUST continue to be valid, even if the
owners or assignees of those names are no longer members or
customers of such organization; this does not mean that there
needs to be resolution of such names, but that they must not
resolve such names to false or stale information and that they
must not be reassigned.
If the underlying namespace is based on an established standard, the
standards body or the organization(s) in charge with the maintenance
of the namespace should be involved in the process, either by
performing the registration on their own, or by supporting the action
of the registrant and asserting support of the registration document.
These aspects, though hard to quantify objectively, should be
considered by organizations/people considering the development of a
Formal URN Namespace, and they will be kept in mind when evaluating
the technical merits of any proposed Formal URN Namespace. The kind
of mandate upon which the organization aims to undertake this
activity might give a strong indication for this evaluation, because
it likely mirrors the trust that other parties (for instance states,
international treaty organizations, professionals' associations,
etc.) put on the organization.
4. URN Namespace Registry: Processes for Registration and Update
Different levels of disclosure are expected/defined for Namespaces.
According to the level of open-forum discussion surrounding the
disclosure, a URN Namespace may be assigned an identifier by IANA or
may request a particular identifier.
The IANA Considerations Guidelines document (BCP 26 [RFC5226])
suggests the need to specify update mechanisms for registrations --
who is given the authority to do so, from time to time, and what are
the processes. Since URNs are meant to be persistently useful, few
(if any) changes should be made to the structural interpretation of
URN strings (e.g., adding or removing rules for lexical equivalence
that might affect the interpretation of URN IDs already assigned).
However, it may be important to introduce clarifications, expand the
list of authorized URN assigners, etc., over the natural course of a
Namespace's lifetime. Specific processes are outlined below.
The official list of registered URN Namespaces is currently
maintained at [IANA-URN]. The registry is subdivided into two sub-
registries, one for "Formal URN Namespaces" and one for "Informal URN
Namespaces", and each entry there links to a stable repository of the
registration document or (an escrow copy of) the filled-out
registration template.
The registration and maintenance procedures vary between the
Namespace types defined in Section 3. The process generally makes
use of the urn-nid@ietf.org discussion list, where, under the
auspices of the designated expert(s), volunteering experts and other
interested parties review URN Namespace proposals.
NOTE: The nominal review period on that list (repeatedly quoted
below) is specified in this document as four weeks. This is an
upper limit intended to grant the experts following the list
sufficient headroom and flexibility. The designated expert(s) may
always come to a conclusion earlier, based on personal judgement,
observation of feedback on the list, and the precedents of a
submission.
Registrations may be revised by updating the Namespace definition
document using the same process as used for initial registrations,
including the circulation of the draft form of the revised Namespace
definition document on the urn-nid discussion list.
4.1. Experimental Namespaces: No Registration
The NIDs of Experimental Namespaces (Section 3.1) are not explicitly
registered with IANA. They SHOULD take the form:
X-<nid>
where <nid> is a string of up to 30 characters, consisting solely of
letters, decimal digits, and hyphen ("-") characters, as specified by
the NID syntax specification in Section 2.1 of RFC 2141bis
[I-D.ietf-urnbis-rfc2141bis-urn].
No provision is made for avoiding collision of experimental NIDs;
they are intended for use within internal or limited experimental
contexts exclusively.
NOTE: The above form is no more considered MANDATORY, in order to
accommodate experience and demonstrated evidence that, under
specific circumstances, experimental prototype systems have to
create and assign identifiers that the interested community
perceives are infeasible to be changed once the Namespace gets
formally registered. However, it is still RECOMMENDED to prefix
eventually targeted NIDs by "X-" during experiments and tests.
As there is no registration, no registration/maintenance procedures
are needed.
Usage of Experimental URN Namespaces MUST be short-lived and whithin
a private scope; it MUST NOT be disclosed to the Internet at large,
e.g., by distribution of software versions that make use of such.
4.2. Informal Namespaces
The NIDs of Informal Namespaces are synthesized by the IANA using an
assigned sequence number (ordinal) and registered in their own sub-
registry, as indicated in Section 4; they take the format:
urn-<number>
where <number> is the decimal representation of a natural number,
with no leading zeroes. This sequence number is assigned by the IANA
on a First-Come-First-Served [RFC5226] basis to registration requests
for Informal Namespaces.
Registrants should send a copy of the registration template (as shown
in Appendix A), duly completed, to the urn-nid@ietf.org mailing list
for review and allow for a four-week discussion period for clarifying
the expression of the registration information and suggestions for
technical improvements to the Namespace proposal.
After suggestions for clarification of the registration information
have been incorporated, the template may be submitted for assignment
of an Informal NID by email to iana@iana.org .
4.3. Formal Namespaces
Formal NIDs are assigned via IETF Review and Expert Review, as
defined in BCP 26 [RFC5226].
"IETF Review" means that the Formal NID application is made via
submission to the IETF of an Internet-Draft that contains the
Namespace definition and targets publication as an RFC of
Informational or Standards-Track category, which needs to be approved
by the IESG after performing an IETF Last Call on the document and
evaluating review comments. The applicant can be an individual or an
IETF working group, in alignment with the designation of the
Internet-Draft. The actual choice should be properly considered by
applicants, but it is RECOMMENDED that the registration documents for
NIDs belonging to an established standard namespace aim at Standards-
Track, whereas other applications aim at Informational RFC.
Before publication can be requested, however, the draft Namespace
specification document must undergo an "Expert Review" process
[RFC5226] pursuant to the guidelines written here (as well as
standard RFC publication guidelines). The designated expert(s) for
URN Namespace registrations are nominated by the IESG, and their role
adheres to the guidelines in BCP 26, unless specified otherwise
below. The template defined in Appendix A SHOULD be included as part
of an RFC-to-be defining some other aspect(s) of the Namespace, but
it MAY be put forward as a Namespace definition document in its own
right. The proposed template (including a pointer to a readily
available copy of the registration document) should be sent to the
urn-nid@ietf.org mailing list for review. This list is monitored by
the designated expert(s). The applicant has to allow for a four-week
discussion period for clarifying the expression of the registration
information, and SHOULD improve the Namespace document and/or
registration template based on the comments received, under the
guidance of the designated expert(s). Multiple iterations can be
performed, before the proposal is accepted and the document can be
forwarded to the IESG for review at large. the
Working groups generally SHOULD seek early expert review for a
Namespace definition document, and individual applicants are also
advised to seek expert comments early enough. The aforementioned
list can be contacted for informal advice at any stage. The document
writeup needed for submitting a working group document to the IESG
requires that all applicable Expert Review processes have been
followed; this applies to the process described here.
NIDs for Formal URN Namespaces MUST NOT have the forms indicated in
the preceding two sections for the other two Namespace types. The
proposed NID string MUST conform with the <nid> syntax rule in
Section 2.1 of RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn] and it
MUST adhere to the following additional constraints:
- not be an already-registered NID;
- not start with "X-" (see Section 4.1 above); 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 7.
- not start with "urn-" (see Section 4.2 above); 6. Defining a URN Namespace
- not start with "xy-", where xy is any combination of 2 ASCII A URN namespace is defined by the following factors:
letters (see NOTE below);
- not be equal to or start with "example" (see NOTE below); o The syntax of URNs assigned within the namespace, in conformance
with the fundamental URN syntax [I-D.saintandre-urnbis-2141bis].
o The process for assigning URNs within the namespace.
o Optionally, the process for resolving URNs issued within the
namepace.
- be more than 2 characters long. 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.
NOTE: All two-letter combinations as well as two-letter combinations 6.1. Formal Namespaces
followed by "-" and any sequence of valid NID characters are
reserved for potential future use as countrycode-based NIDs for
eventual national registrations of URN Namespaces. The definition
and scoping of rules for allocation of responsibility for such
Namespaces is beyond the scope of this document.
Further, to avoid confusion, "urn" is not allowed as an NID
string; To allow neutral example URNs in code and documentation,
NID strings starting with "example" are set aside for use in
documentation; IANA has permanently reserved these string to
prohibit assignment.
Applicants, in concert with the designated expert(s), should ensure Formal NIDs are assigned as a result of IETF Consensus as defined in
that the sought NID strings are "proper" for the designated purpose, the "IANA Considerations" document [RFC5226]. Thus an application
according to common sense (and applicable legal rules). for a formal NID is made by publishing an RFC through normal IETF
processes. The RFC need not be standards track (indeed, to date most
RFCs registering URN namespaces have been informational), but it will
be subject to IESG review and acceptance pursuant to the guidelines
written here (as well as standard RFC publication guidelines).
4.4. Registration Documents 6.1.1. Syntax
The following subsections describe essential, MANDATORY parts of URN A formal namespace registration requests a particular NID, subject to
Namespace registration documents (beyond the registration template the following constraints:
specified in Appendix A), which will be focal in the Expert Review
process and IETF Review.
4.4.1. Namespace Considerations in Registration Documents o It MUST NOT be an already-registered NID.
o It MUST NOT start with "urn-" (which is reserved for informal
namespaces).
o It MUST be more than 2 letters long.
o It MUST NOT start with "XY-", where XY is any combination of two
ASCII letters.
The Namespace definition document MUST include a section with All two-letter combinations, and all two-letter combinations followed
"Namespace Considerations" that outlines the perceived need for a new by "-" and any sequence of valid NID characters, are reserved for
namespace (i.e., where existing namespaces fall short of the potential use as countrycode-based NIDs for eventual national
proposer's requirements). Part of the expected elaborations need to registrations of URN namespaces. The definition and scoping of rules
be the arguments why other identifier systems, in particular a for allocation of responsibility for such countrycode-based
specific/new URI Scheme would not be suitable for the intended namespaces is beyond the scope of this document.
purpose.
The basis for the expected reasoning can be laid by collecting and 6.1.2. Specification
analyzing the requirements for the new namespace or, if an existing
identifier system shall be incorporated into the URN system, from
studying applicable stable (and preferably readily available)
documents related to that identifier system that can be quoted.
Particular insight to properly decide whether a new namespace is
needed can be gained from preparing the explanations to be filled
into clauses of the Registration template in Appendix A related to:
- kind of resources to be named; The specification defining a formal namespace MUST include a
completed namespace definition template (see Section 8).
- URN assignment procedures; The specification also MUST include the following sections.
- URN resolution/delegation; The "Namespace Considerations" section outlines the perceived need
for a new namespace (i.e., where existing namespaces fall short of
the proposer's requirements). Potential considerations include:
- 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
o The type of resources to be identified
o The type of services to be supported
NOTE: It is expected that more than one Namespace may serve the same It is expected that more than one namespace may serve the same
"functional" purpose; the intent of the "Namespace Considerations" "functional" purpose; the intent of the "Namespace Considerations"
section is to provide a record of the proposer's "due diligence" in section is to provide a record of the proposer's "due diligence" in
exploring existing possibilities, for the IESG's consideration. exploring existing possibilities, for the IESG's consideration.
If the need for a new namespace can be demonstrated, it needs to be The "Community Considerations" section explains how the intended
checked whether the requirements and properties of the desired community will benefit by publication of this namespace as well as
identifer system is properly matched to the basic assumptions and how a general Internet user will be able to use the space if they
requirements for URNs -- cf. the Introduction of RFC 2141bis care to do so. Potential considerations include:
[I-D.ietf-urnbis-rfc2141bis-urn]. If that is not obvious, it needs
to be explained in detail in the Namespace Considerations.
See the trailing NOTE of the next Section for exceptional conditions
that might allow to waive the need for presenting the above-described
rationale in a standalone section of a particular Namespace
definition document.
4.4.2. Community Considerations in Registration Documents
The Namespace definition document MUST also include a section with
"Community Considerations" that indicates the dimensions upon which
the proposer expects its community to be able to benefit by
publication of this Namespace, as well as how a general Internet user
will be able to use the space if they care to do so.
Again, insight into arguments needed here might be possible to be
gained by preparing the material to be filled into clauses of the
Registration template in Appendix A related to:
- (open) assignment and use of identifiers within the Namespace;
- open operation of resolution servers for the Namespace
(server);
- creation of software that can meaningfully resolve and access
services for the Namespace (client).
NOTE: It is acknowledged that occasionally the Namespace
Considerations and Community Considerations are closely
intertwined; e.g., this has has been observed in the context of
legacy identifier systems to be embedded into a URN Namespace.
If such circumstances can be demonstrated, the Expert Review
process can waive the requirement to present the two independent
sections of a Namespace defintition document described in this and
the preceding Section and concede to the applicant(s) to combine
the content required for those two mandatory sections into a
single "Namespace and Community Considerations" section.
4.4.3. Security Considerations in Registration Documents
According to the general procurements for RFCs, URN Namespace
definition documents must include a "Security Considerations" section
(cf. BCP 72 [RFC3552]). That section has to identify the security
considerations specific to the subject URN Namespace. If the subject
URN Namespace is based on an underlying namespace, the registration
can include substantive security considerations described in
specifications related to that particular namespace by reference to
these documents. For general security considerations regarding URN
usage (and more generally, URI usage), for the sake of clarity and
brevity, it should refer to the Security Considerations in STD 63
[RFC3986] and in the URN Syntax document
[I-D.ietf-urnbis-rfc2141bis-urn].
4.4.4. IANA Considerations in Registration Documents
According to the general procurements for RFCs, URN Namespace
definitions documents must include an "IANA Considerations" section
(cf. BCP 26 [RFC5226]). That section has to indicate that the
document includes a URN Namespace registration template that is to be
entered into the IANA registry of either Informal or Formal URN
Namespaces.
The completed Namespace registration template included in (or
referred by) the IANA Considerations section in the published form of
Registration documents will provide the particular, unique NID string
that has been assigned, in case of formal Namespaces, by the
Standards/Protocol Action of the IESG that approved the publication
of the registration document as an RFC, or, in case of informal
Namespaces, by the IANA after successful Expert Review. As specified
above in Section 4.3, draft registration documents for formal
Namespaces usually carry the NID suggested by the registrant (subject
to the expert review process); otherwise the NID will be assigned by
the IANA. RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn] specifies
that NID strings are ASCII strings that are interpreted in a case-
insensitive manner, but the NID string SHALL be registered in the
capitalization form preferred by the registrant. Additional
syntactical constraints for NIDs are specified (per Namespace type)
in Sections 4.2 and 4.3 above.
Applicants and the designated expert(s) have to ensure that the
sought NID strings are suitable and proper for the designated purpose
and not misleading, according to common sense and applicable legal
rules. The IETF Review process gives interested parties the
opportunity to rise concerns if they want to challenge proposed
strings; the final approval decision still remains with the IESG.
To avoid clerical accidents, the IANA Considerations Section in
Namespace registration documents should clearly spell out the
implications of the registration on the URN Query Parameters
registries defined in RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn],
if any. Namespace registration documents have to specify the use or
non-use of query instructions (by registered keyword) by the
resolvers related to the respective namespace. Additionally, they
can optionally define new query keywords (of specific scope) for that
Namespace or an entire group of Namespaces.
5. Security Considerations
This document largely focuses on providing mechanisms for the
declaration of public information. Nominally, these declarations
should be of relatively low security profile; however, there is
always the danger of "spoofing" and providing mis-information.
Information in these declarations should be taken as advisory.
6. IANA Considerations
This document outlines the processes for registering URN Namespaces,
and has implications for the IANA in terms of registries to be
maintained, as previously defined in RFC 3406 [RFC3406]. This
document replaces RFC 3406; it contains a revised description for the
management of the "Uniform Resource Names (URN) Namespaces" IANA
Registry that uses the policy designation terms from BCP 26, RFC 5226
[RFC5226], but does not introduce significant changes to the
applicable procedures described in Section 4 of this RFC.
IANA is asked to update the applicable policy for the registry of
Formal URN Namespaces in the list of protocol parameter registries at
http://www.iana.org/protocols/, replacing "IETF Consensus Action" by
"IETF Review after expert review on the urn-nid discussion list
(designated expert: ...)".
In both sub-registries of [IANA-URN] (for Formal and Informal
Namespaces), the registry column headings "URN Namespaces" should be
changed to "Namespace ID", and "Value" to "Ordinal"; preferably these
columns should be swapped in both sub-registries.
[[ DISCUSS: Do we actually need these numerical columns at all? ]]
IANA is asked to add to both sub-registries of [IANA-URN] a new third
column entitled "Kind of named resources"; entries into this column
shall be captured from the respective clause of received registration
templates conforming to Appendix A. For legacy entries, the original
registrants are encouraged to provide proper short descriptions to
IANA.
[[ DISCUSS: Shall *we* provide sensical values for legacy entries
and/or actively poll the Namespace owners instead? ]]
All references there to the predecessor, [RFC3406], should be
replaced by references to this document.
We would appreciate a reorganization of the Registry web page to make
the registration templates for Informal URN Namespaces directly
linked from the main page; this would make the page /assignments/
urn-informal.htm page dispensable (for persistency's sake, the web
server should redirect requests to the /assignments/urn-namespaces
page.
Section 4 of this document outlines the general procedures. Sections
4.2 and 4.3 above describe the syntax rules for NIDs to which the
registry needs to obey.
As pointed out in Section 4.3 above and in RFC 2141bis
[I-D.ietf-urnbis-rfc2141bis-urn], the string "urn" is permanently
reserved and MUST NOT be assigned as an NID. All strings starting
with "example" are permanently reserved for use in code and
documentation, and hence MUST NOT be assigned as an NID.
In conformance with BCP 100 [RFC4020], in all cases of new Namespace
registration proposals, the IANA should provisionally assign the
appropriate NID (informal or formal), as described throughout the
body of this memo, once an IESG-designated expert has confirmed that
the requisite registration process steps have been completed. These
registrations become permanent and can be made publicly available
once the registration document has been approved by the IESG for
publications as a Standards-Track or Informational RFC.
Once a Namespace registration template has been accepted for IANA
processing, the IANA is expected to also update the "Supported by"
lists in the registry specified by Section 9.2.1 of RFC 2141bis
[I-D.ietf-urnbis-rfc2141bis-urn], based on the information supplied
in the "Usage of query instructions" clause of the registration
template.
7. Acknowledgements
This document is heavily based on RFC 3406 (and thereby its
predecessor, RFC 2611), authored by Leslie Daigle, Dirk-Willem van
Gulik, Renato Ianella, and Patrik Faltstrom, whose work is cordially
acknowledged.
This document also been inspired by other recent documents that have
updated important IANA registries, and the countless authors and
contributors to these efforts are acknowledged anonymously.
Several individuals in the URNbis working group have participated in
the detailed discussion of this memo. Particular thanks for detailed
review comments and text suggestions go to (in alphabetical order)
Leslie Daigle Juha Hakala, Subramanian Moonesamy. Peter Saint-Andre,
Lars Svensson, and Mykyta Yevstifeyev.
8. References
8.1. Normative References
[I-D.ietf-urnbis-rfc2141bis-urn]
Hoenes, A., "Uniform Resource Name (URN) Syntax",
draft-ietf-urnbis-rfc2141bis-urn-03 (work in progress),
October 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform o Open assignment and use of identifiers within the namespace
Resource Identifier (URI): Generic Syntax", STD 66, o Open operation of resolution servers for the namespace (server)
RFC 3986, January 2005. o Creation of software that can meaningfully resolve and access
services for the namespace (client)
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an The "IANA Considerations" section indicating that the document
IANA Considerations Section in RFCs", BCP 26, RFC 5226, includes a URN NID registration that is to be entered into the IANA
May 2008. registry of URN NIDs.
8.2. Informative References 6.2. Informal Namespaces
[IANA] IANA, "The Internet Assigned Numbers Authority", Informal namespaces are directly requested of IANA.
<http://www.iana.org/>.
[IANA-URN] The namespace identifier assigned by IANA is a number sequence in the
IANA, "Uniform Resource Names (URN) Namespace Registry", format:
<http://www.iana.org/assignments/urn-namespaces/>.
[RFC2276] Sollins, K., "Architectural Principles of Uniform Resource "urn-" <number>
Name Resolution", RFC 2276, January 1998.
[RFC2611] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, where <number> is chosen by the IANA on a First Come First Served
"URN Namespace Definition Mechanisms", BCP 33, RFC 2611, basis as specified in the "IANA Considerations" deocument [RFC5226].
June 1999.
[RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/ The only restrictions on <number> are (1) that it consist strictly of
IETF URI Planning Interest Group: Uniform Resource digits and (2) that it not cause the NID to exceed the length
Identifiers (URIs), URLs, and Uniform Resource Names limitations defined in the URN syntax specification
(URNs): Clarifications and Recommendations", RFC 3305, [I-D.saintandre-urnbis-2141bis].
August 2002.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 7. Registering a URN Namespace
Internet: Timestamps", RFC 3339, July 2002.
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 7.1. Formal Namespaces
Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS) The key steps for registration of a formal namespace are:
Part Five: URI.ARPA Assignment Procedures", BCP 65,
RFC 3405, October 2002.
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 1. Write an Internet-Draft that includes all of the information
"Uniform Resource Names (URN) Namespace Definition described under Section FIXME.
Mechanisms", BCP 66, RFC 3406, October 2002. 2. Send the completed namespace definition template to the
urn-nid@ietf.org discussion list for technical review.
3. Update the Internet-Draft as needed to address feedback, and
repeat steps 2 and 3 as needed.
4. Based on comments received, update the Internet-Draft and repeat
steps 2 and 3 as necessary.
5. Send a request to the IESG to publish the I-D as an RFC. The
IESG may request further changes (published as I-D revisions)
and/or direct discussion to designated working groups, area
experts, etc.
6. If the IESG approves the document for publication as an RFC, send
a request to IANA to register the requested NID.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC A registration can be revised by updating the RFC through normal IETF
Text on Security Considerations", BCP 72, RFC 3552, processes [RFC2606]. The authors of the revised document need to
July 2003. follow the same steps outlined above for new registrations.
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 7.2. Informal Namespaces
Standards Track Code Points", BCP 100, RFC 4020,
February 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax The key steps for registration of an informal namespace are:
Specifications: ABNF", STD 68, RFC 5234, January 2008.
Appendix A. URN Namespace Definition Template 1. Complete the namespace definition template (see Section 8). This
can be done as part of an Internet-Draft.
2. Send the completed template to the urn-nid@ietf.org discussion
list for technical review.
3. Based on comments received, update the template and repeat steps
2 and 3 as necessary.
4. Once comments have been addressed and the review period has
expired, send a registration request to IANA (via the
iana@iana.org email address) with the final template.
Definition of a URN Namespace is accomplished by completing the Informal namespaces can also be revised by updating the template and
following information template. It is provided in two versions; the processing it as outlined above for new registrations.
annotated template with comments explaining what should go into the
filled-out template is shown in Appendix A.1 and the plain template
that can be used as a starting point for filling in the required
information via plaintext editing is shown in Appendix A.2.
To further the application of the template, both forms will be made
available in xml2rfc form on the IETF Tools and/or IANA web site [[
to be decided ]].
In case of (unintended) deviations, Appendix A.1 takes precedence
over Appendix A.2.
Apart from providing a mechanism for disclosing the structure of the 8. URN Namespace Definition Template
URN Namespace, this information is designed to be useful for
- entities seeking to have a URN assigned in a Namespace (if Definition of a URN namespace is accomplished by completing the
applicable) and following template. Apart from providing a mechanism for defining
the structure of URNs assigned within the namespace, this information
is designed to be useful for:
- entities seeking to provide URN resolvers for a Namespace (if o entities seeking to have a URN assigned in a namespace (if
applicable). applicable)
o entities seeking to provide URN resolvers for a namespace (if
applicable)
This is particularly important for communities evaluating the This is particularly important for communities evaluating the
possibility of using a portion of an existing URN Namespace rather possibility of using a portion of an existing URN namespace rather
than creating their own. than creating their own.
Applications for Formal URN Namespaces must also document "Namespace As described under Section 7.1, applications for formal URN
Considerations", "Community Considerations", "Security namespaces MUST also document "Namespace Considerations", "Community
Considerations", and "IANA Considerations", as described in Considerations" and "IANA Considerations".
Section 4.4.
A.1. Annotated URN Namespace Definition Template
Information in the template is as follows (text in curly braces
describes the expected content and should be removed from filled-in
templates):
Namespace ID:
{ If request is for an Informal NID, indicate so; the number will
be assigned by IANA. In the case of a Formal NID registration,
regularly a particular NID string will be requested. }
Kind of named resources:
{ Short description of what resources are named under this NID. }
Registration Information:
{ This is information to identify the particular version of
registration information: }
- version number:
{ starting with 1, incrementing by 1 with each new version }
- date:
{ date submitted to the IANA or date of approval of
registration document, using the format outlined in "Date and
Time on the Internet: Timestamps", [RFC3339]: YYYY-MM-DD }
Declared registrant of the Namespace:
- Registering organization:
Name: { ... }
Address: { ... }
- Designated contact person:
Name: { ... }
{ Address: ...
(at least one of: Email, Phone, Postal address) }
Declaration of syntactic structure of NSS part:
{
This clause should outline any structural features of identifiers
in this Namespace. At the very least, this description may be
used to introduce terminology used in other clauses. This
structure may also be used for determining realistic caching/
shortcuts approaches; suitable caveats should be provided. If
there are any specific character encoding rules (e.g., which
character should always be used for single-quotes), these should
be listed here.
Answers might include, but are not limited to:
- the structure is opaque (no exposition);
- a regular expression for parsing the identifier into
components, including naming authorities;
- formal syntax of the NSS, preferably in ABNF (STD 68
[RFC5234]).
}
Relevant ancillary documentation:
{
This clause should list any RFCs, standards, or other published
documentation that defines or explains all or part of the
namespace structure.
Answers might include, but are not limited to:
- RFCs that outline the syntax of the namespace;
- other documents of the defining community (e.g., ISO) that
outline the syntax of the identifiers in the namespace;
- explanatory material that introduces the namespace.
}
Conformance with URN Syntax:
{
This clause should outline any special considerations required for
conforming with the URN syntax. This is particularly applicable
in the case of legacy naming systems that are used in the context
of URNs.
For example, if a namespace is used in contexts other than URNs,
it may make use of characters that are reserved in the URN syntax.
This clause should flag any such characters, and outline necessary
mappings to conform to URN syntax. Normally, this will be handled
by percent-encoding the symbol.
}
Rules for Lexical Equivalence of NSS part:
{
If there are particular algorithms for determining equivalence
between two identifiers in the underlying namespace (and hence, in
the URN string itself), rules can be provided here.
Some examples include:
- equivalence between hyphenated and non-hyphenated groupings in
the identifier string;
- equivalence between single-quotes and double-quotes;
- namespace-defined equivalences between specific characters,
such as "character X with or without diacritic marks".
Note that these are not normative statements for any kind of best
practice for handling equivalences between characters; they are
statements limited to reflecting the namespace's own rules.
However, namespaces that seek to provide higher-level lexical
equivalence rules should preferably make use of established and
standardized normalization procedures (like the methods leading to
the various Unicode Normalization Forms, which would have to be
applied before UTF-8 encoding) and not invent their own "magic";
in practice, the utility of such things is likely to be limited
since test of lexical equivalence is a typical client-side pre-
screening operation performed by applications that try to remain
as general as possible and typically will not have built-in, NID-
specific knowledge -- ultimately, functional (or semantical)
equivalence of URNs can only be decided in the NID-specific
assignment/resolution systems, and their internal rules can be
handled much more flexibly than more complicated, nailed-down
lexical equivalence rules that are unlikely to be implemented at
large.
}
Usage of query instructions:
{
Either say "not applicable" or describe the query instructions
(keywords and associated values) supported by the resolvers for
this Namespace (cf. Sections 2.5 and 9.2 of RFC 2141bis).
Is the "s" keyword supported to select component resources?
If yes: Which registered services can be selected with it? What
is the default/fallback service if "s=" is not given or if the
value specified for it is unknown/unsupported?
For which services is the "c" keyword supported (if any)?
If affirmative, specify the values that can be used with it and
the behavior if an unrecognized / inapplicable value is used.
}
Usage of fragment part:
{
Either say "not applicable" if <fragment> parts cannot sensically
be used with URI references to URNs of this NID,
or specify (by URN service supported) which media types that
support fragment identifiers will be returned by the resolvers for
this Namespace, and the <fragment> designators that will be
applicable. (Cf. Section 2.4 of RFC 2141bis.)
}
Identifier uniqueness considerations:
{
This clause should address the requirement that URN identifiers be
assigned uniquely -- they are assigned to at most one resource,
and are not reassigned.
(Note that the definition of "resource" is fairly broad; for
example, information on "Today's Weather" might be considered a
single resource, although the content is dynamic.)
Possible answers include, but are not limited to:
- exposition of the structure of the identifiers, and
partitioning of the space of identifiers amongst assignment
authorities that are individually responsible for respecting
uniqueness rules;
- identifiers are assigned sequentially;
- information is withheld; that is, the namespace is opaque.
}
Identifier persistence considerations:
{
Although non-reassignment of URN identifiers ensures that a URN
will persist in identifying a particular resource even after the
"lifetime of the resource", some consideration should be given to
the persistence of the usability of the URN. This is particularly
important in the case of URN Namespaces providing global
resolution.
Possible answers include, but are not limited to:
- quality of service considerations.
}
Process of identifier assignment:
{
This clause should detail the mechanisms and/or authorities for
assigning URNs to resources. It should make clear whether
assignment is completely open, or if limited, how to become an
assigner of identifiers, and/or get one assigned by existing
assignment authorities.
Answers could include, but are not limited to:
- assignment is completely open, following a particular
algorithm;
- assignment is delegated 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:
{
Which URN resolution services will be supported?
What is the default service provided by the resolvers for this
Namespace?
(The "Usage of query instructions:" clause above only reports
which services can be selected by the "s" query instruction, if
any.)
}
{
If a Namespace is intended to be accessible for global resolution,
it must be registered in an RDS (Resolution Discovery System, see
RFC 2276 [RFC2276]) such as the DDDS (see RFC 3401 [RFC3401]).
Resolution then proceeds according to standard URI resolution
processes, and the mechanisms of the RDS. What this clause should
outline is the requirements for becoming a recognized resolver of
URNs in this Namespace (and being so listed in the RDS registry).
Answers may include, but are not limited to:
- the Namespace is not listed with an RDS, this is not relevant;
- resolution mirroring is completely open, with a mechanism for
updating an appropriate RDS;
- resolution is controlled by entities to which assignment has
been delegated.
}
Validation mechanism:
{
Apart from attempting resolution of a URN, a URN Namespace may
provide mechanisms for "validating" a URN -- i.e., determining
whether a given string is currently a validly-assigned URN. There
are 2 issues here: 1) users should not "guess" URNs in a
Namespace; 2) when the URN Namespace is based on an existing
identifier system, it may not be the case that all the existing
identifiers are assigned on Day 0. The reasonable expectation is
that the resource associated with each resulting URN is somehow
related to the thing identified by the original identifier system,
but those resources may not exist for each original identifier.
For example, even if a telephone number-based URN Namespace was
created, it is not clear that all telephone numbers would
immediately become "valid" URNs, that could be resolved using
whatever mechanisms are described as part of the Namespace
registration.
Validation mechanisms might be:
- a syntax grammar;
- an on-line service;
- an off-line service.
}
Scope:
{
This clause should outline the scope of the use of the identifiers
in this namespace, i.e. the precise kind of resources to which the
URNs are assigned. Apart from considerations of private vs.
public namespaces, this clause is critical in evaluating the
applicability of a requested NID. For example, a namespace
claiming to deal with "social security numbers" should have a
global scope and address all social security number structures
(unlikely). On the other hand, at a national level, it is
reasonable to propose a URN Namespace for "this nation's social
security numbers".
}
A.2. Plain URN Namespace Definition Template (Informative)
Namespace ID: ...
Kind of named resources: ...
Registration Information:
- version number: _
- date: yyyy-mm-dd
Declared registrant of the Namespace:
- Registering organization:
Name: ...
Address: ...
- Designated contact person:
Name: ...
{ Address: ... }
Declaration of syntactic structure of NSS part:
...
Relevant ancillary documentation:
...
Conformance with URN Syntax:
...
Rules for Lexical Equivalence of NSS part:
...
Identifier uniqueness considerations:
...
.. [[ to be completed in next draft rev if this idea is accepted ]]
...
Appendix B. Summary of Registration Steps (Informative)
The key steps for registration of Informal or Formal Namespaces
typically play out as follows:
A) Informal NID:
1. Complete the registration template. This may be done as part
of an Internet-Draft.
2. Communicate the registration template to urn-nid@ietf.org for
technical review -- as an email with a pointer to the
submitted I-D or inline text containing the template.
3. Update the registration template (and/or document) as
necessary from comments, and repeat steps 2 and 3 as
necessary.
4. Once comments have been addressed (and the review period has
expired), send a request to IANA with the revised registration
template.
B) Formal NID:
1. Write an Internet-Draft describing the namespace and include
the registration template, duly completed. Be sure to include
"Namespace Considerations" and "Community Considerations"
sections (or a combined section for these), "Security
Considerations" and "IANA Considerations" sections, as
described in Section 4.4.
2. Submit the Internet-Draft, and send a pointer to the I-D
(perhaps using a copy of the I-D announcement) to
urn-nid@ietf.org in order to solicit technical review.
3. Update the Internet-Draft as necessary from comments, and
repeat steps 2 and 3 as needed.
4. If the Internet-Draft is the product of a working group in the
IETF, follow the usual WG process to forward the document to
the IESG for publication as an RFC. Otherwise, find a
sponsoring Area Director willing to guide the draft through
the IESG. The IESG (or the IETF at large in case an IETF-wide
last call is deemed necessary) may request further changes
(submitted as I-D revisions) and/or direct discussion to
designated working groups, area experts, etc.
5. The IESG evaluation process includes a review by IANA, and if
the IESG approves the document for publication as an RFC, IANA
processing of the document will follow the regular work-flow
between the RFC Editor and IANA. This way, the NID
registration will be made public by IANA when the RFC is
published.
Appendix C. Changes from RFC 3406 (Informative)
C.1. Essential Changes since RFC 3406
[ RFC Editor: please remove the Appendix C.1 headline and all The information to be provided in the template is as follows:
subsequent subsections of Appendix C starting with Appendix C.2. ]
[[ T.B.D. in next iteration of this memo. ]] Namespace ID:
C.2. Changes from RFC 3406 to URNbis WG Draft -00 Requested of IANA (formal) or assigned by IANA (informal).
o Abstract: rewritten entirely; Registration Information:
o Section 1 (Introduction): added historical RFC information; This is information to identify the particular version of
registration information:
o Section 1.1 (Requirements Language): added; - registration version number: starting with 1,
incrementing by 1 with each new version
- registration date: date submitted to the IANA, using the
format YYYY-MM-DD
o Section 3.1: added Note that challenges the utility of Declared registrant of the namespace:
Experimental Namespaces and raises question of whether formal This includes:
"provisional" registrations would be useful; Registering organization
Name
Address
Designated contact person
Name
Coordinates (at least one of email address, phone
number, postal address)
o Section 4: text expanded and updated; background material added; Declaration of syntactic structure:
added Note to challenge IANA website practices;
o Section 4.2 ff: changed "home" of URN-NID registration discussion This section ought to outline any structural features of
list (it already had been moved to the IETF Secretariat servers); identifiers in this namespace. At the very least, this
description may be used to introduce terminology used in
other sections. This structure may also be used for
determining realistic caching/shortcuts approaches;
suitable caveats ought to be provided. If there are any
specific character encoding rules (e.g., which character
ought to always be used for single-quotes), these ought
to be listed here.
o Section 4.2: added Note to challenge the 2-week review period; in Answers might include, but are not limited to:
current practice, that is almost always exceeded, and some regard
it as too short;
o Section 4.3: largely clarified procedures as they happen in - the structure is opaque (no exposition)
practice; adapted language for conformance with RFC 5226; use new - a regular expression for parsing the identifier into
home of URN-NID (as mentioned above); the registration template components, including naming authorities
(Appendix A) now "SHOULD" be used;
o Section 4.3: split off new Section 4.4 on Registration Documents, Relevant ancillary documentation:
because registrants essentially are encouraged to follow these
guidelines for Informal Namespaces as well, as far as practical;
replaced "RFC" by "Registration Document"; Section 4.4 is
subdivided for all mandatory sections;
o Section 4.4.1: made requirements a "MUST"; This section ought to list any RFCs, standards, or other
published documentation that defines or explains all or
part of the namespace structure.
o Sections 4.4.1 and 4.4.2: added common Note that challenges the Answers might include, but are not limited to:
need to split Namespace and Community Considerations, based on
observed problems in practice to separate the topics, and pointing
to overlap with clauses in the registration template due to
bullets listed that are not so clearly related to the headlines
under which they appear; suggestion is to avoid duplication, place
factual stuff into the template and focus on rationale in these
Considerations, perhaps in a common section;
o Section 4.4.3: added discussion of Security Considerations - RFCs outlining syntax of the namespace
section; advice is to focus on namespace-specific considerations - Other of the defining community's (e.g., ISO) documents
and refer to the SecCons in the "generic" RFCs for the general outlining syntax of the identifiers in the namespace
issues; - Explanatory material introducing the namespace
o Section 4.4.4: amended discussion of IANA Considerations section; Identifier uniqueness considerations:
this tries to reflect standing practice and codifies that Formal
NIDs are generally proposed by the registrant; added Note that
"urn" is permanently reserved and MUST NOT be assigned as a NID,
to avoid confusion (as also specified in RFC 2141bis draft); wrt
registration maintenance: got rid of wrong reference in RFC 3406
(to RFC 2606);
o Section 6 (IANA Considerations): updated and rephrased description This section ought to address the requirement that URNs are
of the role of this document, including a sketch of the history; assigned uniquely -- i.e., they are assigned to at most one
added teat that tries to precisely describe what is expected from resource, and are not reassigned.
IANA on approval of this draft; added text on procedures and
suggest a provisional assignment practice upon "thumbs-up" of the
IANA Expert to protect prospective registrants from collateral
damage on NID precedence in case the document suffers from delays
unrelated to the registration template before it eventually gets
approved;
o Section 7 (Acknowledgements): added; (Note that the definition of "resource" is fairly broad; for
example, information on "Today's Weather" might be considered
a single resource, although the content is dynamic.)
o References: Updated and amended references; added pointers to Possible answers include, but are not limited to:
chartered URNbis work items; removed entirely outdated example
material related to legacy documents;
o Appendix A and B.1: added words on Security Considerations - exposition of the structure of the identifiers, and
section; partitioning of the space of identifiers amongst assignment
authorities which are individually responsible for
respecting uniqueness rules
- identifiers are assigned sequentially
- information is withheld; the namespace is opaque
o Appendix A (Registration Template): clarified role of text Identifier persistence considerations:
snippets in the Template: hint and commentary now all enclosed in
curly braces, with not that these parts shall be removed when
filling in the tempalte; indicate that Formal NIDs are normally
proposed by registrant; changed date/time ref. from ISO 8601 to
RFC 3339; use inherited term "percent-encoding";
o Appendix A -- structure: moved formal clauses on Conformance with Although non-reassignment of URN identifiers ensures that a URN
URN Syntax and Rules for Lexical Equivalence to vicinity of will persist in identifying a particular resource even after
namespace specific syntax clause, to which these are closely the "lifetime of the resource", some consideration ought to be
related; given to the persistence of the usability of the URN. This is
particularly important in the case of URN namespaces providing
global resolution.
o Appendix A -- changes of clauses: the Declaration of syntactic Possible answers include, but are not limited to:
structure and Rules for Lexical Equivalence clauses now
tentatively have been restricted to the NSS part only; this change
is described in NOTEs and motivated by the observation of repeated
confusion in past and present registration documents, which
hopefully can be avoided (and the job of the Expert and reviewers
made easier) by leaving discussion of the invariate parts that
cannot be re-specified there at the single place where they belong
to: the NID is fully specified in the initial clause, rules for
the NID and the URI scheme name "urn" are inherited from RFC
2141[bis] and RFC 3986, respectively, and hence the new clause
descriptions avoid conflict by taking these components out of
scope of these clauses;
o Appendix B.1 (Example Template): facelifted a bit; concerns with - quality of service considerations
IESG policy on examples in RFCs raised in a NOTE;
o Appendix B.2 (Registration steps in practice): updated and Process of identifier assignment:
clarified description of procedure, in alignment to current
practice;
o Appendix C: removed "Changes from RFC 2611"; added this change This section ought to detail the mechanisms and/or authorities
log; 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, and/or get one assigned by existing
assignment authorities.
o General: numerous editorial changes and enhancements, following Answers could include, but are not limited to:
contemporary RFC style.
C.3. Changes from URNbis WG I-D -00 to -01 - assignment is completely open, following a particular
algorithm
- assignment is delegated to authorities recognized by a
particular organization (e.g., the Digital Object Identifier
Foundation controls the DOI assignment space and its
delegation)
- assignment is completely closed (e.g., for a private
organization)
Usage of terminology strenghtened. Process for identifier resolution:
Clarified role and usage of Experimental Namespaces. If a namespace is intended to be accessible for global
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).
Clarified NID strings for Formal Namespaces. Answers may include, but are not limited to:
Added hint that recommends Std. Track RFCs for NID applications based - the namespace is not listed with an RDS; therefore this
on established standard namespaces, and Informational for others. 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
Changed standard review period from 2 to 4 weeks (pending Rules for Lexical Equivalence:
discussion).
Resolved with IANA: simple, traditional and generic URL used by IANA If there are particular algorithms for determining equivalence
for the URN Namespace registry. (Needed to be re-opened in -02!) between two identifiers in the underlying namespace (hence, in
the URN string itself), rules can be provided here.
Numerous editorial enhancements and fixes. Some examples include:
C.4. Changes from URNbis WG I-D -01 to -02 - 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".
General text edits based on evaluation of meeting and on-list Note that these are not normative statements for any kind of
comments. best practice for handling equivalences between characters;
they are statements limited to reflecting the namespace's
own rules.
Updated and tightened the organizatorial requirements for Formal Conformance with URN Syntax:
Namespace requests.
Restored additional IANA Considerations -- due to observed defects. This section ought to outline any special considerations
required for conforming with the URN syntax. This is
particularly applicable in the case of legacy naming
systems that are used in the context of URNs.
Reserved NID strings "example.*" for documentation (as suggested by For example, if a namespace is used in contexts other than URNs,
Larry Masinter, Peter Saint-Andre, and Julian Reschke). it may make use of characters that are reserved in the URN
syntax.
Added text on possible "higher level" methods to establish lexical This section ought to flag any such characters, and outline
equivalence of URNs, with the caveats that such things are rather necessary mappings to conform to URN syntax. Normally, this
unlikely to get traction in general-purpose client software. will be handled by hex encoding the symbol.
Removed historical Appendix B.1 (Example Template). For example, see the section on SICIs in RFC 2288.
Various editorial enhancements and fixes. Validation mechanism:
Updated and expanded "Issues" Appendix (below) in preparation of Apart from attempting resolution of a URN, a URN namespace may
usage of the IETF Issue Tracker. provide mechanisms for "validating" a URN -- i.e., determining
whether a given string is currently a validly-assigned URN.
There are two issues here: 1) users ought not "guess" URNs in
a namespace; 2) when the URN namespace is based on an existing
identifier system, it may not be the case that all the existing
identifiers are assigned on Day 0. The reasonable expectation
is that the resource associated with each resulting URN is
somehow related to the thing identified by the original
identifier system, but those resources may not exist for each
original identifier. For example, even if a URN namespace were
defined based on telephone numbers, it is not clear that all
telephone numbers would immediately become "valid" URNs, that
could be resolved using whatever mechanisms are described as
part of the namespace registration.
C.5. Changes from URNbis WG I-D -02 to -03 Validation mechanisms might be:
Due to the scattered discussion of the previous draft version, the - a syntax grammar
items below not only list effected changes but also give rationale - an on-line service
for where suggested changes have not been applied. - an off-line service
Document title shortened to better reflect entire purpose of Scope:
document.
Abstract: revised and shortened (comments from SM). This section ought to outline the scope of the use of the
identifiers in this namespace. Apart from considerations of
private vs. public namespaces, this section is critical in
evaluating the applicability of a requested NID. For example,
a namespace claiming to deal in "social security numbers"
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".
Introduction: 9. Security Considerations
Rephrased 1st para to put emphasis on name binding property (derived
from list discussion on related topic, Keith Moore et al.).
Amended / modified text to better reflect the intended audience of
the memo and its contents, and to accommodate the evolution of the
rfc2141bis I-D.
Wordsmithing Assumption: "_well_ recognized" (Lars Svensson).
Contrary to a proposal (PSA), the draft text keeps the Assumptions
separate from the consequences/conclusions drawn from these; the
registration process is what is to be followed to maintain the
assumption, not the 2nd assumption itself.
Text reworked based on comments (SM, PSA, et al.).
The single paragraph with a historical perspective on previous
documents is deemed rather helpful for the intended audience (note
the confusing artifact caused by RFC Editor mistake, giving the
replacement of a BCP a different BCP number!), and it serves to
capture important motivations for the document revision effort;
therefore, it is kept in the draft.
The pargraph describing the purpose of the document has been
rephrased. It isn't barely about an IANA procedure, it is also about
what prospective registrants are well advised to consider before
deciding on a new Namespace and the processes they have to implement,
and finally capturing the results in a URN Namespace registration
document.
Section 2: This document largely focuses on providing mechanisms for the
Amended by text describing the 3 methods available to Namespace declaration of public information. Nominally, these declarations
designers / stakeholdes to make component resources of structured will be of relatively low security profile, however there is always
resources identifiable/accessible. the danger of "spoofing" and providing mis-information. Information
Some existing text reworded based on comments (SM et al.). in these declarations ought to be taken as advisory.
It has been argued that text on URN Namespaces in s2 would better be
placed into the rfc2141bis document, but on the other hand, it has
been argued that text introducing and discussing Namespace properties
from rfc2141bis should better be placed into this memo. To keep both
documents as much self-contained as practical, text on URN Namespaces
of specific interest to prospective stakeholders of URN Namespaces
and authors of registration documents has been kept in s2 of this
draft, and new such material has been added there. (The rfc2141bis
draft now points to this.)
s3.3: Reworded "benefit" clause to clarify distinction between the 10. IANA Considerations
community interested in a new Namespace and the Internet community at
large (corollary to comments on and revision of s4.4.2.).
s4: (dealing with comments from SM, PSA) This document outlines the processes for registering URN namespaces,
The justification for the need to consider and specify registration and has implications for the IANA in terms of registries to be
maintenance procedures has been in RFC 3406; the text from there has maintained. In all cases, the IANA ought to assign the appropriate
been updated according to our chartered, to update for RFC 5226. NID (informal or formal), as described above, once an IESG-designated
This matter needs to be taken into account by prospective Namespace expert has confirmed that the requisite registration process steps
owners, and thus the text makes sense in this document. have been completed.
Reorganization of subsequent text made it logically necessary to
include into this section a high level description of the
urn-nid@ietf.org list. The nominal review period is left a four
weeks in this draft revision, but a Note has been added to s4
indicating that this is an upper limit to accommodate headroom,
whereas the designated expert(s) may always come to a conclusion
earlier.
Repeated references to IANA have been consolidated.
The common shorthand designation "IANA experts" for the designated
expert(s) supporting IANA in the maintenance of the URN NID registry
is now being avoided.
s4.1: No technical changes. The continued use of the "X-" prefix for 11. References
Experimental Namespaces does not violate RFC 6648 because this is
legacy practice, experimental NIDs are not being registered, and this
memo again prohibits the use of Experimental Namespaces in the open
Internet.
s4.3: 11.1. Normative References
Text reorganized, incorporating material from s4.4.4 (see below).
The text on the (modified) "IETF Review" policy has been upgraded
from RFC 3406 (and thereby effectively shortened). It serves to give
concise information to the expected primary audience of the document,
applicants for Namespaces, which according to experience are rather
unlikely inclined to read the full RFC 5226, but just need to know
what is said in the single sentence in the draft. Further, this
sentence supplies the background information for the following
sentences and thus improved the readability of the text. Therefore,
no substantive changes applied here.
s4.4: text amended to avoid confusion about registration template. [I-D.saintandre-urnbis-2141bis]
Saint-Andre, P. and R. Moats, "Uniform Resource Name (URN)
Syntax", draft-saintandre-urnbis-2141bis-00 (work in
progress), October 2012.
s4.4.1 and s4.4.2: Heavily reworked based on discussion (Leslie, PSA, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Juha, et al.). Bullet lists now point to clauses of the registration Requirement Levels", BCP 14, RFC 2119, March 1997.
template where working on the text to be supplied there will likely
give insights to answer the basic questions to be answered here.
A NOTE now tentatively allows to include a combined Namespace and
Community Considerations section into a Namespace registration
document, if the expert review admits it.
s4.4.3: The first sentence lays the foundation for the subsequent [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
sentences and gives the appropriate reference (to BCP 72); hence it IANA Considerations Section in RFCs", BCP 26, RFC 5226,
is regarded as non-disposable -- no change. May 2008.
Repeated negative experience has motivated the addition of a hint
that emphasizes that WG documents including URN Namespace definitions
need to go through the urn-nid process before they can be forwarded
to the IESG (document writeup requirement).
s4, s4.4.4: Last paragraph ostensibly belonging to s4.4.4 moved to 11.2. Informative References
end of s4, then adjusted to context. (The RFC format doesn't allow
to recognize the continuation of a higher-level section after the
inclusion of sub-sections.)
s4.3, s4.4.4: The checklist of syntactical constraints for NIDs of [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
formal namespaces was intended as a checklist for IANA; following Names", BCP 32, RFC 2606, June 1999.
comments from Lars Svensson, it has been moved from s4.4.4 to s4.3
and related text has been modified accordingly.
s4.4.4: substantially revised (comments from Lars Svensson et al.). [RFC2611] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"URN Namespace Definition Mechanisms", BCP 33, RFC 2611,
June 1999.
IANA Cons. (s6): Added request to IANA to clarify the procedures for [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
Formal NIDs in the list of ptorocol parameter registries. "Uniform Resource Names (URN) Namespace Definition
Mechanisms", BCP 66, RFC 3406, October 2002.
Updated and expanded Acknowledgements. [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, June 2012.
References: RFC 3339 demoted to Informational; you don't need to read Appendix A. Changes from RFC 3406
it to insert the date into the registration template, the applicable
pattern is shown there directly; this change avoids a potential
normative downref.
Clarified role of Appendices. Although on the surface it might appear that this document is
significantly different from [RFC3406], in general it only modifies
the order of presentation, with the intent of making it easier for
people to define and register URN namespaces. However, the only
major substantive change is removing the category of experimental
namespaces, in accorance with [RFC6648].
Appendix A: Authors' Addresses
Clarified purpose of the explanations in curly braces embedded in the
annotated registration template. Use term "clause" throughout.
Removed Notes from template that served to explain previous changes.
Template now provided in both annotated and bare form (suggestion
from SM); once finalized, both forms will be provided in xml2rfc
format (location to be decided: IETF Tools and/or IANA).
Added new items to registration template for Purpose of Namespace
(short description of named resources), applicability of <query> part
and supported query instructions (if any), and applicability of
<fragment> part.
Appendix B: The document organization is carried over from RFC 3406. Peter Saint-Andre (editor)
Modified title of App. B, declared it Informative. Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600
Denver, CO 80202
USA
This Appendix C.5 added; previous Appendix D (Issues) dropped. Phone: +1-303-308-3282
Email: psaintan@cisco.com
Multiple editorial fixes and enhancements. Leslie Daigle
Author's Address Dirk-Willem van Gulik
Alfred Hoenes (editor) Renato Iannella
TR-Sys
Gerlinger Str. 12
Ditzingen D-71254
Germany
EMail: ah@TR-Sys.de Patrick Faltstrom
 End of changes. 156 change blocks. 
1439 lines changed or deleted 502 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/