draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt   draft-ietf-urnbis-rfc3406bis-urn-ns-reg-03.txt 
IETF URNbis WG A. Hoenes IETF URNbis WG A. Hoenes, Ed.
Internet-Draft TR-Sys Internet-Draft TR-Sys
Obsoletes: 3406 (if approved) March 12, 2012 Obsoletes: 3406 (if approved) October 19, 2012
Intended status: BCP Intended status: BCP
Expires: September 13, 2012 Expires: April 22, 2013
Uniform Resource Name (URN) Namespace Definition Mechanisms Defining Uniform Resource Name (URN) Namespaces
draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-03
Abstract Abstract
Uniform Resource Names (URNs) are intended to serve as persistent, RFC 2141bis formalizes the concept of Uniform Resource Names (URNs)
location-independent, resource identifiers. To structure and for persistent, location-independent, resource identifiers within the
organize their usage, the URN syntax (RFC 2141bis) specifies a generic URI system specified in RFC 3986. To structure and organize
hierarchy that divides the set of possible URNs into "URN Namespaces" URN usage, RFC 2141bis specifies a hierarchy that divides the set of
that can be individually defined and managed. URN Namespaces in possible URNs into "URN Namespaces" that can be individually defined
particular serve to map existing identifier systems into the URN and managed. URN Namespaces allow to map existing identifier systems
system and thereby make available generic, network-based resolution into the URN scheme and thereby make available generic, network-based
services for the identified documents, artifacts, and other objects resolution services for the identified resources (documents,
(and metadata related to them). artifacts, and other objects) and metadata related to them.
To achive these goals, URN Namespaces need to be specified in a To this end, URN Namespaces need to be defined and specified in a
comparable manner, and their Namespace Identifiers (NIDs) need to be comparable manner, and their Namespace Identifiers (NIDs) need to be
registered with IANA, so that naming conflicts are avoided and registered with IANA, so that naming conflicts are avoided and
implementers of services can follow a structured approach in support implementers of services can follow a structured approach in support
of various namespaces, guided by the registry to the related of various namespaces, guided by the registry to the related
documents and the particularities of specific namespaces, as documents and the particularities of specific namespaces, as
described in these Namespace registration documents. described in these Namespace registration documents.
This RFC serves as a guideline for authors of URN Namespace This RFC serves as a design guideline for stakeholders of URN
definition and registration documents and the process to be followed Namespaces and authors of URN Namespace definition and registration
to register a URN Namespace with IANA. It describes the essential documents. It describes the process to be followed to register a URN
content of such documents and how they shall be structured to allow Namespace with IANA and the essential content of such documents.
readers familar with the scheme to quickly assess the properties of a
specific URN Namespace.
This document is a companion document to the revised URN Syntax This document supersedes and replaces RFC 3406.
specification, RFC 2141bis; it supersedes and replaces RFC 3406.
Discussion Discussion
Discussion of this memo utilizes the urn@ietf.org mailing list. 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 September 13, 2012. This Internet-Draft will expire on April 22, 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 9 skipping to change at page 3, line 9
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirement Language and Terminology . . . . . . . . . . . 5 1.1. Requirement Language and Terminology . . . . . . . . . . . 5
2. What is a URN Namespace? . . . . . . . . . . . . . . . . . . . 5 2. What is a URN Namespace? . . . . . . . . . . . . . . . . . . . 6
3. URN Namespace (Registration) Types . . . . . . . . . . . . . . 7 3. URN Namespace (Registration) Types . . . . . . . . . . . . . . 8
3.1. Experimental Namespaces . . . . . . . . . . . . . . . . . 7 3.1. Experimental Namespaces . . . . . . . . . . . . . . . . . 8
3.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 7 3.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 8
3.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 7 3.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 8
4. URN Namespace Registry: Processes for Registration and 4. URN Namespace Registry: Processes for Registration and
Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Experimental Namespaces: No Registration . . . . . . . . . 10 4.1. Experimental Namespaces: No Registration . . . . . . . . . 11
4.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 10 4.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 12
4.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 11 4.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 13
4.4. Registration Documents . . . . . . . . . . . . . . . . . . 12 4.4. Registration Documents . . . . . . . . . . . . . . . . . . 14
4.4.1. Namespace Considerations in Registration Documents . . 12 4.4.1. Namespace Considerations in Registration Documents . . 14
4.4.2. Community Considerations in Registration Documents . . 13 4.4.2. Community Considerations in Registration Documents . . 15
4.4.3. Security Considerations in Registration Documents . . 14 4.4.3. Security Considerations in Registration Documents . . 16
4.4.4. IANA Considerations in Registration Documents . . . . 14 4.4.4. IANA Considerations in Registration Documents . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. URN Namespace Definition Template . . . . . . . . . . 18 Appendix A. URN Namespace Definition Template . . . . . . . . . . 21
Appendix B. Registration steps in practice . . . . . . . . . . . 24 A.1. Annotated URN Namespace Definition Template . . . . . . . 21
Appendix C. Changes from RFC 3406 . . . . . . . . . . . . . . . . 25 A.2. Plain URN Namespace Definition Template (Informative) . . 27
C.1. Essential Changes since RFC 3406 . . . . . . . . . . . . . 25 Appendix B. Summary of Registration Steps (Informative) . . . . . 28
C.2. Changes from RFC 3406 to URNbis WG Draft -00 . . . . . . . 25 Appendix C. Changes from RFC 3406 (Informative) . . . . . . . . . 29
C.3. Changes from URNBIS WG I-D -00 to -01 . . . . . . . . . . 28 C.1. Essential Changes since RFC 3406 . . . . . . . . . . . . . 29
C.4. Changes from URNBIS WG I-D -01 to -02 . . . . . . . . . . 28 C.2. Changes from RFC 3406 to URNbis WG Draft -00 . . . . . . . 29
Appendix D. Issues in this Draft . . . . . . . . . . . . . . . . 28 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 resource identifiers adhering to Uniform Resource Names (URNs) are identifiers bound to resources with
the specific requirements of enabling location-independent the objective to provide location-independent identification of these
identification of a resource, as well as longevity of reference. resources as well as longevity of reference. URNs are part of the
URNs are part of the larger Uniform Resource Identifier (URI) family larger Uniform Resource Identifier (URI) family (see the joint W3C/
(see the joint W3C/IETF memorandum, RFC 3305 [RFC3305], and the IETF IETF memorandum, RFC 3305 [RFC3305], and the IETF STD 66, RFC 3986
STD 66, RFC 3986 [RFC3986]) with the specific goal of providing [RFC3986]), with the specific goal of persistent binding names to
persistent naming of resources. resources.
The URN Syntax (see below and RFC 2141bis The URN scheme formalized in RFC 2141bis
[I-D.ietf-urnbis-rfc2141bis-urn]) structures and organizes the [I-D.ietf-urnbis-rfc2141bis-urn] structures and organizes the
entirety of URNs into a hierarchy that divides the set of possible entirety of URNs into a hierarchy that divides the set of possible
URNs into "URN Namespaces" that can be individually defined, managed, URNs into "URN Namespaces" that can be individually defined, managed,
and (optionally) further subdivided. URN Namespaces in particular and (optionally) further subdivided. URN Namespaces in particular
serve to map existing identifier systems into the URN system and serve to map existing identifier systems into the URN system and
thereby make available generic, network-based resolution services for thereby make available generic, network-based resolution services for
the identified documents, artifacts, and other objects (and their the identified resources (documents, artifacts, abstract concepts,
metadata). and other objects) and their metadata.
There are two assumptions that are key to this document: There are two assumptions that are key to this document:
Assumption #1: Assignment of a URN is a managed process. Assumption #1: Assignment of a URN is a managed process.
I.e., not all strings that conform to URN syntax are necessarily I.e., not all strings that conform to URN syntax are necessarily
valid URNs. A URN is assigned according to the rules of a valid URNs. A URN is assigned according to the rules of a
particular namespace (in terms of syntax, semantics, and process). particular namespace (in terms of syntax, semantics, and process).
Assumption #2: The space of URN Namespaces is managed. Assumption #2: The space of URN Namespaces is managed.
I.e., not all syntactically correct URN Namespaces (per the URN I.e., not all syntactically correct URN Namespace identifiers (per
syntax definition) are valid URN Namespaces. A URN Namespace must the URN syntax definition) designate valid URN Namespaces. A URN
have a recognized definition in order to be valid. Namespace must have a well recognized definition in order to be
valid.
To actually leverage the potential synergetic advantage of this To actually draw benefits from this unification (structured embedding
unification (structured embedding of existing namespaces into the URN of existing namespaces into the URN framework), URN Namespaces have
framework), URN Namespaces need to be specified in a comparable common design considerations, they need to be specified in a
manner, and their Namespace Identifiers (NIDs) need to be centrally comparable manner, and their Namespace Identifiers (NIDs) need to be
registered, so that naming conflicts are avoided and implementers of centrally registered, so that naming conflicts are avoided and
services can follow a structured approach in support of various implementers of services can follow a structured approach in support
namespaces, guided by the registry to the related documents and the of various namespaces, guided by the registry to the related
particularities of specific namespaces, as described in these documents and the particularities of specific namespaces, as
Namespace registration documents. described in these URN Namespace registration documents.
The purpose of this document is to outline a mechanism and provide a The primary purpose of this document is to outline a mechanism for
template for explicit URN Namespace definition, as well as provide explicit URN Namespace definition, associating it with an identifier
the mechanism for associating an identifier (called a "Namespace ID", (called a "Namespace ID", or NID). To this end, this RFC defines the
or NID), which is registered with the Internet Assigned Numbers requirements for URN NID specification documents and provides a
Authority (IANA) [IANA] in the URN Namespaces registry maintained at registration template, which is to be registered with the Internet
[IANA-URN]. 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 The URN Namespace definition and registration mechanisms originally
have been specified in RFC 2611 [RFC2611], which has been obsoleted have been specified in BCP 33, RFC 2611 [RFC2611], which has been
by BCP 66, RFC 3406 [RFC3406]. Guidelines for documents prescribing obsoleted by BCP 66, RFC 3406 [RFC3406]. Guidelines for documents
IANA procedures have been revised as well over the years, and at the prescribing IANA procedures have been revised as well over the years,
time of this writing, BCP 26, RFC 5226 [RFC5226] is the normative and at the time of this writing, BCP 26, RFC 5226 [RFC5226] is the
document. This document is a revision of RFC 3406 based on the normative document. This document is a revision of RFC 3406 based on
revised URN Syntax specification RFC 2141bis the revised specification of URNs in RFC 2141bis
[I-D.ietf-urnbis-rfc2141bis-urn] and RFC 5226. [I-D.ietf-urnbis-rfc2141bis-urn] and RFC 5226.
The reader is referred to Section 1.1 of RFC 2141bis The reader is referred to Section 1.1 of RFC 2141bis
[I-D.ietf-urnbis-rfc2141bis-urn] for a more detailed synopsis of the [I-D.ietf-urnbis-rfc2141bis-urn] for a more detailed synopsis of the
history of documents fundamental for URNs. history of documents fundamental for URNs.
Note that this document restricts itself to the description of Note that this document restricts itself to the description of
processes for the creation of URN Namespaces. If generic processes for the creation of URN Namespaces. If generic
"resolution" of any so-created URN identifiers is desired, a separate "resolution" of any so-created URN identifiers is desired, a separate
process of registration in a global NID directory, such as that process of registration in a global NID directory, such as that
proposed by the DDDS system [RFC3401], is necessary. See [RFC3405] proposed by the DDDS system [RFC3401], is necessary. See [RFC3405]
for information on obtaining registration in the DDDS global NID for information on obtaining registration in the DDDS global NID
directory. There also is work in progress [Ref: t.b.d.] to establish directory. RFC 2141bis establishes an IANA registry for URN
an IANA registry for URN services, such that registration documents services, such that registration documents can unambiguously identify
can unambiguously identify such services and discuss their such services and discuss their applicability to the particular URN
applicability to the particular URN Namespace. Namespace.
1.1. Requirement Language and Terminology 1.1. Requirement Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", When spelled in all-capitals as in this paragraph, the key words
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
document are to be interpreted as described in RFC 2119 [RFC2119]. "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
In this document, these key words describe requirements for the are to be interpreted as described in BCP 14 [RFC2119]. In this
process to be followed and the content to be provided in URN document, these key words describe requirements for the process to be
Namespace definition documents and registration templates. 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 For the purpose of this document, its subject is spelled "URN
Namespace" (in headline case), whereas in other context, "namespace" Namespace" (in headline case), whereas in other context, "namespace"
is spelled in lower case, e.g. to designate a (standard or non- is spelled in lower case, e.g., to designate a (standard or non-
standard) identifier system on which a URN Namespace is based. standard) identifier system on which a URN Namespace is based.
2. What is a URN Namespace? 2. What is a URN Namespace?
For the purposes of URNs, a "namespace" is a collection of uniquely- For the purposes of URNs, a "namespace" is a collection of uniquely-
assigned identifiers. That is, the identifiers are not ever assigned assigned identifiers. That is, the identifiers are not ever assigned
to more than one resource. These resources may be stable (e.g., a to more than one resource. These resources may be stable (e.g., a
doctoral dissertation or an abstract concept of a protocol) or doctoral dissertation or an abstract concept of a protocol) or
dynamic (e.g., a continuously evolving web site of a periodical or a dynamic (e.g., a continuously evolving web site of a periodical or a
specific protocol parameter registry subject to additions and specific protocol parameter registry subject to additions and
skipping to change at page 6, line 47 skipping to change at page 7, line 5
The development of an identifier structure, and thereby a collection The development of an identifier structure, and thereby a collection
of identifiers, is a process that is inherently dependent on the of identifiers, is a process that is inherently dependent on the
requirements of the community defining the identifier, how they will requirements of the community defining the identifier, how they will
be assigned, and the uses to which they will be put. All of these 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 issues are specific to the individual community seeking to define a
namespace (e.g., publishing community, association of booksellers, namespace (e.g., publishing community, association of booksellers,
protocol developers, technology-specific vendor groups, etc.); they protocol developers, technology-specific vendor groups, etc.); they
are beyond the scope of the IETF URN work. are beyond the scope of the IETF URN work.
If a namespace contains structured resources, per RFC 2141bis
[I-D.ietf-urnbis-rfc2141bis-urn] the designers of a related URN
Namespace and the implementers of the related resolution systems have
available three options for the Namespace to support identification
and resolution of component resources:
a. A Namespace can choose to assign individual identifiers
(Namespace Specific String, NSS) to some or all components of a
structured resource that is also named by the identifier system.
This method is independent of the Internet media types the
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
interprets the 'component' ("c=") directive that can be
incorporated in the <query> part of URI references to URNs (see
[I-D.ietf-urnbis-rfc2141bis-urn]). This way, only the basic
resources are assigned an NSS -- which will simplify the
identifier assignment/registration processes/systems for the
namespace, or even be dictated by existing processes/systems --
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
particular resolution services might specify how resolution
clients can make use of <fragment> identifiers contained in URI
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. Future Namespace definitions MUST document the methods applicable
to it and available via its resolvers.
This document outlines the processes by which a collection of This document outlines the processes by which a collection of
identifiers satisfying certain constraints (uniqueness of assignment, identifiers satisfying certain constraints (uniqueness of assignment,
etc.) can become a bona fide URN Namespace by obtaining a NID. In a etc.) can become a bona fide URN Namespace by obtaining a NID. In a
nutshell, a template for the definition of the Namespace is completed nutshell, a template for the definition of the Namespace is completed
for deposit with IANA, and a NID is assigned. The details of the for deposit with IANA, and a NID is assigned. The details of the
process and possibilities for NID strings are outlined below. process and possibilities for NID strings are outlined below.
3. URN Namespace (Registration) Types 3. URN Namespace (Registration) Types
There are three categories (types) of URN Namespaces defined here, There are three categories (types) of URN Namespaces defined here,
skipping to change at page 8, line 17 skipping to change at page 9, line 24
It is however expected that Formal NIDs may be applied to Namespaces It is however expected that Formal NIDs may be applied to Namespaces
where some aspects are not fully open. For example, a Namespace may where some aspects are not fully open. For example, a Namespace may
make use of a fee-based, privately managed, or proprietary registry make use of a fee-based, privately managed, or proprietary registry
for assignment of URNs in the Namespace, but it may still provide for assignment of URNs in the Namespace, but it may still provide
benefit to some Internet users if the services associated with it benefit to some Internet users if the services associated with it
have openly published access protocols. have openly published access protocols.
In addition to the basic registration information defined in the In addition to the basic registration information defined in the
registration template (in Appendix A), a Formal Namespace request registration template (in Appendix A), a Formal Namespace request
must be accompanied by documented considerations of the need for a must be accompanied by documented considerations of the need for a
new Namespace and of the community benefit from formally establishing new Namespace and of the benefit for the Internet community from
the proposed URN Namespace. formally establishing the proposed URN Namespace -- see Sections
4.4.1 and 4.4.2 below.
Additionally, since the goal of URNs is to provide persistent Additionally, since the goal of URNs is to provide persistent
identification, careful consideration must be given to the longevity identification, careful consideration must be given to the longevity
and maintainability of the URN Namespace. The collective experience and maintainability of the URN Namespace. The collective experience
of the IETF community contains a wealth of information on technical of the IETF community contains a wealth of information on technical
factors that will prevent longevity of identification. Thus, the factors that will prevent longevity of identification. Thus, the
IESG may elect not to accept a proposed Namespace registration if the IESG may elect not to accept a proposed Namespace registration if the
IETF community consensus is that the registration document contains IETF community consensus is that the registration document contains
technical flaws that will prevent (or seriously impair the technical flaws that will prevent (or seriously impair the
possibility of) persistent identification, and that it therefore possibility of) persistent identification, and that it therefore
skipping to change at page 8, line 48 skipping to change at page 10, line 12
Namespace can continue to be usable/useful if the organization Namespace can continue to be usable/useful if the organization
ceases to be able to foster it; ceases to be able to foster it;
- the organization(s) assigning URNs within the URN Namespace should - the organization(s) assigning URNs within the URN Namespace should
demonstrate ability and competency in name assignment; this should demonstrate ability and competency in name assignment; this should
improve the likelihood of persistence (e.g., to minimize the improve the likelihood of persistence (e.g., to minimize the
likelihood of conflicts); likelihood of conflicts);
- the organization(s) assigning URNs within the URN Namespace need - the organization(s) assigning URNs within the URN Namespace need
to be committed to honor the scope, rules, and regulations to be committed to honor the scope, rules, and regulations
outlined its registration document and the documents defining the outlined in its registration document and the documents defining
underlying namespace and covering its identifier assignment and the underlying namespace and covering its identifier assignment
maintenance procedures (if any), and the organization maintaining and maintenance procedures (if any), and the organization
the URN Namespace needs to have procedures in force that aim at maintaining the URN Namespace needs to have procedures in force
ensuring this adherance at a very high confidence level; and that aim at ensuring this adherance at a very high confidence
level; and
- the involved organization(s) need to commit to not re-assign - the involved organization(s) need to commit to not re-assign
existing names; old names MUST continue to be valid, even if the existing names; old names MUST continue to be valid, even if the
owners or assignees of those names are no longer members or owners or assignees of those names are no longer members or
customers of such organization; this does not mean that there customers of such organization; this does not mean that there
needs to be resolution of such names, but that they must not needs to be resolution of such names, but that they must not
resolve such names to false or stale information and that they resolve such names to false or stale information and that they
must not be reassigned. must not be reassigned.
If the underlying namespace is based on an established standard, the If the underlying namespace is based on an established standard, the
skipping to change at page 9, line 33 skipping to change at page 10, line 47
of mandate upon which the organization aims to undertake this of mandate upon which the organization aims to undertake this
activity might give a strong indication for this evaluation, because activity might give a strong indication for this evaluation, because
it likely mirrors the trust that other parties (for instance states, it likely mirrors the trust that other parties (for instance states,
international treaty organizations, professionals' associations, international treaty organizations, professionals' associations,
etc.) put on the organization. etc.) put on the organization.
4. URN Namespace Registry: Processes for Registration and Update 4. URN Namespace Registry: Processes for Registration and Update
Different levels of disclosure are expected/defined for Namespaces. Different levels of disclosure are expected/defined for Namespaces.
According to the level of open-forum discussion surrounding the According to the level of open-forum discussion surrounding the
disclosure, a URN Namespace may be assigned an identifier or may disclosure, a URN Namespace may be assigned an identifier by IANA or
request a particular identifier. may request a particular identifier.
The IANA Considerations Guidelines document (BCP 26 [RFC5226]) The IANA Considerations Guidelines document (BCP 26 [RFC5226])
suggests the need to specify update mechanisms for registrations -- suggests the need to specify update mechanisms for registrations --
who is given the authority to do so, from time to time, and what are 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 the processes. Since URNs are meant to be persistently useful, few
(if any) changes should be made to the structural interpretation of (if any) changes should be made to the structural interpretation of
URN strings (e.g., adding or removing rules for lexical equivalence URN strings (e.g., adding or removing rules for lexical equivalence
that might affect the interpretation of URN IDs already assigned). that might affect the interpretation of URN IDs already assigned).
However, it may be important to introduce clarifications, expand the However, it may be important to introduce clarifications, expand the
list of authorized URN assigners, etc., over the natural course of a list of authorized URN assigners, etc., over the natural course of a
Namespace's lifetime. Specific processes are outlined below. Namespace's lifetime. Specific processes are outlined below.
The official list of registered URN Namespaces is currently The official list of registered URN Namespaces is currently
maintained by IANA at [IANA-URN]. 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 registry is subdivided into two sub-registries, one for "Formal The registration and maintenance procedures vary between the
URN Namespaces" and one for "Informal URN Namespaces", and each entry Namespace types defined in Section 3. The process generally makes
there links to a stable repository of the registration document or use of the urn-nid@ietf.org discussion list, where, under the
(an escrow copy of) the filled-out registration template. auspices of the designated expert(s), volunteering experts and other
interested parties review URN Namespace proposals.
The registration and maintenance procedures vary slightly between the NOTE: The nominal review period on that list (repeatedly quoted
Namespace types. 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 4.1. Experimental Namespaces: No Registration
The NIDs of Experimental Namespaces (Section 3.1) are not explicitly The NIDs of Experimental Namespaces (Section 3.1) are not explicitly
registered with IANA. They SHOULD take the form: registered with IANA. They SHOULD take the form:
X-<nid> X-<nid>
where <nid> is a string of up to 30 characters, consisting solely of where <nid> is a string of up to 30 characters, consisting solely of
letters, decimal digits, and hyphen ("-") characters, as specified by letters, decimal digits, and hyphen ("-") characters, as specified by
the NID syntax specification in Section 2.1 of RFC 2141bis the NID syntax specification in Section 2.1 of RFC 2141bis
[I-D.ietf-urnbis-rfc2141bis-urn]. [I-D.ietf-urnbis-rfc2141bis-urn].
No provision is made for avoiding collision of experimental NIDs; No provision is made for avoiding collision of experimental NIDs;
they are intended for use within internal or limited experimental they are intended for use within internal or limited experimental
contexts exclusively. contexts exclusively.
Note: The above form is no more considered MANDATORY, in order to NOTE: The above form is no more considered MANDATORY, in order to
accommodate experience and demonstrated evidence that, under accommodate experience and demonstrated evidence that, under
specific circumstances, experimental prototype systems have to specific circumstances, experimental prototype systems have to
create and assign identifiers that the interested community create and assign identifiers that the interested community
perceives are infeasible to be changed once the Namespace gets perceives are infeasible to be changed once the Namespace gets
formally registered. However, it is strongly RECOMMENDED to formally registered. However, it is still RECOMMENDED to prefix
prefix eventually targeted NIDs by "X-" during experiments and eventually targeted NIDs by "X-" during experiments and tests.
tests.
As there is no registration, no registration/maintenance procedures As there is no registration, no registration/maintenance procedures
are needed. are needed.
Usage of Experimental URN Namespaces MUST be short-lived and whithin Usage of Experimental URN Namespaces MUST be short-lived and whithin
a private scope; it MUST NOT be disclosed to the Internet at large, 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. e.g., by distribution of software versions that make use of such.
4.2. Informal Namespaces 4.2. Informal Namespaces
The NIDs of Informal Namespaces are synthesized by the IANA using an The NIDs of Informal Namespaces are synthesized by the IANA using an
assigned sequence number and registered in their own sub-registry, as assigned sequence number (ordinal) and registered in their own sub-
indicated in Section 4; they take the format: registry, as indicated in Section 4; they take the format:
urn-<number> urn-<number>
where <number> is the decimal representation of a natural number, where <number> is the decimal representation of a natural number,
with no leading zeroes. This sequence number is assigned by the IANA with no leading zeroes. This sequence number is assigned by the IANA
on a First-Come-First-Served [RFC5226] basis to registration requests on a First-Come-First-Served [RFC5226] basis to registration requests
for Informal Namespaces. for Informal Namespaces.
Registrants should send a copy of the registration template (as shown Registrants should send a copy of the registration template (as shown
in Appendix A), duly completed, to the urn-nid@ietf.org mailing list 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 for review and allow for a four-week discussion period for clarifying
the expression of the registration information and suggestions for the expression of the registration information and suggestions for
technical improvements to the Namespace proposal. technical improvements to the Namespace proposal.
[[ Editorial NOTE: An even longer time is needed in practice! Should
we further increase the upper limit to 8 weeks? ]]
After suggestions for clarification of the registration information After suggestions for clarification of the registration information
have been incorporated, the template may be submitted for assignment have been incorporated, the template may be submitted for assignment
of a NID by email to iana@iana.org . of an Informal NID by email to iana@iana.org .
Registrations may be updated later by the original registrant, or by
an entity designated by the registrant, by updating the registration
template, submitting it to the discussion list for a further four-
week discussion period, and finally resubmitting it to IANA in a
message to iana@iana.org .
4.3. Formal Namespaces 4.3. Formal Namespaces
Formal NIDs are assigned via IETF Review, as defined in BCP 26 Formal NIDs are assigned via IETF Review and Expert Review, as
[RFC5226]. The designated expert(s) for URN Namespace registrations defined in BCP 26 [RFC5226].
are nominated by the IESG, and their role adheres to the regulations
in BCP 26, unless specified otherwise below.
NIDs for Formal URN Namespaces MUST NOT have the forms indicated in
the preceding two sections for the other two Namespace types. (The
detailed formal rules are given below in Section 4.4.4.) Applicants,
in concert with the IANA experts, should ensure that the sought NID
strings are "proper" for the designated purpose, according to common
sense (and applicable legal rules).
"IETF Review" (per [RFC5226]) means that the Formal NID application "IETF Review" means that the Formal NID application is made via
is made via submission to the IETF of an Internet-Draft that contains submission to the IETF of an Internet-Draft that contains the
the Namespace definition and targets publication as an RFC of Namespace definition and targets publication as an RFC of
Informational or Standards-Track category, which needs to be approved Informational or Standards-Track category, which needs to be approved
by the IESG after performing an IETF Last Call on the document and by the IESG after performing an IETF Last Call on the document and
evaluating review comments. The applicant can be an individual or an evaluating review comments. The applicant can be an individual or an
IETF working group, in alignment with the designation of the IETF working group, in alignment with the designation of the
Internet-Draft. The actual choice should be properly considered by Internet-Draft. The actual choice should be properly considered by
applicants, but it is RECOMMENDED that the registration documents for applicants, but it is RECOMMENDED that the registration documents for
NIDs belonging to an established standard namespace aim at Standards- NIDs belonging to an established standard namespace aim at Standards-
Track, whereas other applications aim at Informational RFC. Track, whereas other applications aim at Informational RFC.
Before publication can be requested, however, the draft Namespace Before publication can be requested, however, the draft Namespace
specification document must undergo an Expert Review process specification document must undergo an "Expert Review" process
[RFC5226] pursuant to the guidelines written here (as well as [RFC5226] pursuant to the guidelines written here (as well as
standard RFC publication guidelines). The template defined in standard RFC publication guidelines). The designated expert(s) for
Appendix A SHOULD be included as part of an RFC-to-be defining some URN Namespace registrations are nominated by the IESG, and their role
other aspect(s) of the Namespace, but it MAY be put forward as a adheres to the guidelines in BCP 26, unless specified otherwise
Namespace definition document in its own right. The proposed below. The template defined in Appendix A SHOULD be included as part
template (including a pointer to a readily available copy of the of an RFC-to-be defining some other aspect(s) of the Namespace, but
registration document) should be sent to the urn-nid@ietf.org mailing it MAY be put forward as a Namespace definition document in its own
list for review. This list is monitored by the designated expert(s). right. The proposed template (including a pointer to a readily
The applicant has to allow for a four-week discussion period for available copy of the registration document) should be sent to the
clarifying the expression of the registration information, and SHOULD urn-nid@ietf.org mailing list for review. This list is monitored by
improve the Namespace document and/or registration template based on the designated expert(s). The applicant has to allow for a four-week
the comments received, under the guidance of the designated discussion period for clarifying the expression of the registration
expert(s), before the IESG reviews the document. 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 Working groups generally SHOULD seek early expert review for a
Namespace definition document, before they hand it over to the IESG, Namespace definition document, and individual applicants are also
and individual applicants are also advised to seek expert comments advised to seek expert comments early enough. The aforementioned
early enough. The aforementioned list can be contacted for informal list can be contacted for informal advice at any stage. The document
advice at any stage. writeup needed for submitting a working group document to the IESG
requires that all applicable Expert Review processes have been
followed; this applies to the process described here.
NIDs for Formal URN Namespaces MUST NOT have the forms indicated in
the preceding two sections for the other two Namespace types. The
proposed NID string MUST conform with the <nid> syntax rule in
Section 2.1 of RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn] and it
MUST adhere to the following additional constraints:
- not be an already-registered NID;
- not start with "X-" (see Section 4.1 above);
- not start with "urn-" (see Section 4.2 above);
- not start with "xy-", where xy is any combination of 2 ASCII
letters (see NOTE below);
- not be equal to or start with "example" (see NOTE below);
- be more than 2 characters long.
NOTE: All two-letter combinations as well as two-letter combinations
followed by "-" and any sequence of valid NID characters are
reserved for potential future use as countrycode-based NIDs for
eventual national registrations of URN Namespaces. The definition
and scoping of rules for allocation of responsibility for such
Namespaces is beyond the scope of this document.
Further, to avoid confusion, "urn" is not allowed as an NID
string; To allow neutral example URNs in code and documentation,
NID strings starting with "example" are set aside for use in
documentation; IANA has permanently reserved these string to
prohibit assignment.
Applicants, in concert with the designated expert(s), should ensure
that the sought NID strings are "proper" for the designated purpose,
according to common sense (and applicable legal rules).
4.4. Registration Documents 4.4. Registration Documents
The following subsections describe essential, MANDATORY parts of URN The following subsections describe essential, MANDATORY parts of URN
Namespace registration documents, which will be focal in the expert Namespace registration documents (beyond the registration template
Review process and IETF Review. specified in Appendix A), which will be focal in the Expert Review
process and IETF Review.
4.4.1. Namespace Considerations in Registration Documents 4.4.1. Namespace Considerations in Registration Documents
The Namespace definition document MUST include a "Namespace The Namespace definition document MUST include a section with
Considerations" section that outlines the perceived need for a new "Namespace Considerations" that outlines the perceived need for a new
namespace (i.e., where existing namespaces fall short of the namespace (i.e., where existing namespaces fall short of the
proposer's requirements). Part of the expected elaborations need to proposer's requirements). Part of the expected elaborations need to
be the arguments why other identifier systems, in particular a be the arguments why other identifier systems, in particular a
specific/new URI Scheme would not be suitable for the intended specific/new URI Scheme would not be suitable for the intended
purpose. purpose.
Considerations MUST include, directly or with the help of referenced The basis for the expected reasoning can be laid by collecting and
stable (and preferably readily available) documents: analyzing the requirements for the new namespace or, if an existing
identifier system shall be incorporated into the URN system, from
studying applicable stable (and preferably readily available)
documents related to that identifier system that can be quoted.
Particular insight to properly decide whether a new namespace is
needed can be gained from preparing the explanations to be filled
into clauses of the Registration template in Appendix A related to:
- kind of resources to be named;
- URN assignment procedures; - URN assignment procedures;
- URN resolution/delegation; - URN resolution/delegation;
- type of resources to be identified;
- type of services to be supported. - type of services to be supported.
NOTE: It is expected that more than one Namespace may serve the same NOTE: 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.
[[ Editorial Note: See the endnote of the next section! If the need for a new namespace can be demonstrated, it needs to be
In particular, the above list (from RFC 3406) seems to be rather checked whether the requirements and properties of the desired
orthogonal to the primary purpose of such section (as indicated in identifer system is properly matched to the basic assumptions and
the first paragraph), namely to provide evidence for the perceived requirements for URNs -- cf. the Introduction of RFC 2141bis
need for the new Namespace. ]] [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 4.4.2. Community Considerations in Registration Documents
The Namespace definition document MUST also include a "Community The Namespace definition document MUST also include a section with
Considerations" section that indicates the dimensions upon which the "Community Considerations" that indicates the dimensions upon which
proposer expects its community to be able to benefit by publication the proposer expects its community to be able to benefit by
of this Namespace, as well as how a general Internet user will be publication of this Namespace, as well as how a general Internet user
able to use the space if they care to do so. will be able to use the space if they care to do so.
Potential considerations include: 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) assignment and use of identifiers within the Namespace;
- open operation of resolution servers for the Namespace - open operation of resolution servers for the Namespace
(server); (server);
- creation of software that can meaningfully resolve and access - creation of software that can meaningfully resolve and access
services for the Namespace (client). services for the Namespace (client).
[[ Editorial Note: NOTE: It is acknowledged that occasionally the Namespace
It is acknowledged that, in many cases, the Namespace Considerations Considerations and Community Considerations are closely
and Community Considerations are closely intertwined. Further, the intertwined; e.g., this has has been observed in the context of
bulleted lists above (from RFC 3406) seems to be more related to the legacy identifier systems to be embedded into a URN Namespace.
items in the registration template entitled "Identifier uniqueness If such circumstances can be demonstrated, the Expert Review
considerations", "Identifier persistence considerations", "Process of process can waive the requirement to present the two independent
identifier assignment", and "Process for identifier resolution" than sections of a Namespace defintition document described in this and
to the primary objectives presented in the first paragraph above the preceding Section and concede to the applicant(s) to combine
(also from RFC 3406). the content required for those two mandatory sections into a
In fact, Namespace registration documents seen so far duplicate in single "Namespace and Community Considerations" section.
the registration template material from the "Community
Considerations" that addresses the above bullets.
Therefore: Should this specification now allow a combined section
"Namespace and Community Considerations" that focuses on the
(non-)utility of possible alternate namespace re-use and the
*benefits* of an independent new Namespace?
]]
4.4.3. Security Considerations in Registration Documents 4.4.3. Security Considerations in Registration Documents
According to the general procurements for RFCs, URN Namespace According to the general procurements for RFCs, URN Namespace
definition documents must include a "Security Considerations" section definition documents must include a "Security Considerations" section
(cf. BCP 72 [RFC3552]). That section has to identify the security (cf. BCP 72 [RFC3552]). That section has to identify the security
considerations specific to the subject URN Namespace. If the subject considerations specific to the subject URN Namespace. If the subject
URN Namespace is based on an underlying namespace, the registration URN Namespace is based on an underlying namespace, the registration
can include substantive security considerations described in can include substantive security considerations described in
specifications related to that particular namespace by reference to specifications related to that particular namespace by reference to
skipping to change at page 14, line 25 skipping to change at page 16, line 44
usage (and more generally, URI usage), for the sake of clarity and usage (and more generally, URI usage), for the sake of clarity and
brevity, it should refer to the Security Considerations in STD 63 brevity, it should refer to the Security Considerations in STD 63
[RFC3986] and in the URN Syntax document [RFC3986] and in the URN Syntax document
[I-D.ietf-urnbis-rfc2141bis-urn]. [I-D.ietf-urnbis-rfc2141bis-urn].
4.4.4. IANA Considerations in Registration Documents 4.4.4. IANA Considerations in Registration Documents
According to the general procurements for RFCs, URN Namespace According to the general procurements for RFCs, URN Namespace
definitions documents must include an "IANA Considerations" section definitions documents must include an "IANA Considerations" section
(cf. BCP 26 [RFC5226]). That section has to indicate that the (cf. BCP 26 [RFC5226]). That section has to indicate that the
document includes a URN Namespace registration that is to be entered document includes a URN Namespace registration template that is to be
into the IANA registry of Formal URN Namespaces. entered into the IANA registry of either Informal or Formal URN
Namespaces.
Registration documents for formal URN Namespaces will provide a
particular, unique, desired NID string, and this will be assigned by
the Standards/Protocol Action of the IESG that approves the
publication of the registration document as an RFC. 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. The proposed NID string MUST conform with the
<nid> syntax rule in Section 2.1 of RFC 2141bis
[I-D.ietf-urnbis-rfc2141bis-urn] and it MUST adhere to the following
additional constraints:
- not be an already-registered NID;
- not start with "X-" (see Section 4.1 above);
- not start with "urn-" (see Section 4.2 above);
- not start with "xy-", where xy is any combination of 2 ASCII
letters (see NOTE below);
- not be equalt to or start with "example" (see NOTE below);
- be more than 2 characters long.
NOTE: All two-letter combinations as well as two-letter combinations The completed Namespace registration template included in (or
followed by "-" and any sequence of valid NID characters are reserved referred by) the IANA Considerations section in the published form of
for potential future use as countrycode-based NIDs for eventual Registration documents will provide the particular, unique NID string
national registrations of URN Namespaces. The definition and scoping that has been assigned, in case of formal Namespaces, by the
of rules for allocation of responsibility for such Namespaces is Standards/Protocol Action of the IESG that approved the publication
beyond the scope of this document. of the registration document as an RFC, or, in case of informal
Further, to avoid confusion, "urn" is not allowed as an NID string; Namespaces, by the IANA after successful Expert Review. As specified
To allow neutral example URNs in code and documentation, NID strings above in Section 4.3, draft registration documents for formal
starting with "example" are set aside for use in documentation; IANA Namespaces usually carry the NID suggested by the registrant (subject
has permanently reserved these string to prohibit assignment. 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 IANA experts have to ensure that the sought NID Applicants and the designated expert(s) have to ensure that the
strings are suitable and proper for the designated purpose and not sought NID strings are suitable and proper for the designated purpose
misleading, according to common sense and applicable legal rules. and not misleading, according to common sense and applicable legal
The IETF Review process gives interested parties the opportunity to rules. The IETF Review process gives interested parties the
rise concerns if they want to challenge proposed strings; the final opportunity to rise concerns if they want to challenge proposed
approval decision still remains with the IESG. strings; the final approval decision still remains with the IESG.
Registrations may be revised by updating the RFC through standard To avoid clerical accidents, the IANA Considerations Section in
IETF RFC update processes. In any case, a revised document, in the Namespace registration documents should clearly spell out the
form of a new Internet-Draft, must be published, and the proposed implications of the registration on the URN Query Parameters
updated template must be circulated on the urn-nid discussion list, registries defined in RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn],
allowing for a four-week review period before pursuing RFC if any. Namespace registration documents have to specify the use or
publication of the new document. 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 5. Security Considerations
This document largely focuses on providing mechanisms for the This document largely focuses on providing mechanisms for the
declaration of public information. Nominally, these declarations declaration of public information. Nominally, these declarations
should be of relatively low security profile; however, there is should be of relatively low security profile; however, there is
always the danger of "spoofing" and providing mis-information. always the danger of "spoofing" and providing mis-information.
Information in these declarations should be taken as advisory. Information in these declarations should be taken as advisory.
6. IANA Considerations 6. IANA Considerations
This document outlines the processes for registering URN Namespaces, This document outlines the processes for registering URN Namespaces,
and has implications for the IANA in terms of registries to be and has implications for the IANA in terms of registries to be
maintained, as previously defined in RFC 3406 [RFC3406]. This maintained, as previously defined in RFC 3406 [RFC3406]. This
document replaces RFC 3406; it contains a revised description for the document replaces RFC 3406; it contains a revised description for the
management of the "Uniform Resource Names (URN) Namespaces" IANA management of the "Uniform Resource Names (URN) Namespaces" IANA
Registry that uses the policy designation terms from BCP 26, RFC 5226 Registry that uses the policy designation terms from BCP 26, RFC 5226
[RFC5226], but does not introduce significant changes to the [RFC5226], but does not introduce significant changes to the
applicable procedures. applicable procedures described in Section 4 of this RFC.
Until recently, that registry has been available in HTML, XML, and IANA is asked to update the applicable policy for the registry of
plain text from the generic web page at Formal URN Namespaces in the list of protocol parameter registries at
<http://www.iana.org/assignments/urn-namespaces/> [IANA-URN]. http://www.iana.org/protocols/, replacing "IETF Consensus Action" by
"IETF Review after expert review on the urn-nid discussion list
(designated expert: ...)".
[[ NOTE: It would be preferable to restore the generic, most In both sub-registries of [IANA-URN] (for Formal and Informal
universally supported (HTML) form of the registry be identified by an Namespaces), the registry column headings "URN Namespaces" should be
implementation-neutral URL, as previously supported by IANA: changed to "Namespace ID", and "Value" to "Ordinal"; preferably these
<http://www.iana.org/assignments/urn-namespaces>. Yet, currently columns should be swapped in both sub-registries.
this URI and similar forms all resolve to an XML version. [[ DISCUSS: Do we actually need these numerical columns at all? ]]
The content there should link to alternate forms (.xml, .txt), and
those alternate versions should indicate the *other* versions; i.e., IANA is asked to add to both sub-registries of [IANA-URN] a new third
where the .txt version (currently only available at ftp.IANA.ORG) column entitled "Kind of named resources"; entries into this column
also says, "This registry is also available in XML and plain text shall be captured from the respective clause of received registration
formats.", it should better say: "This registry is also available in templates conforming to Appendix A. For legacy entries, the original
HTML and XML formats." Similarly, the XML form should point to the registrants are encouraged to provide proper short descriptions to
HTML and plain text forms. ]] 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 All references there to the predecessor, [RFC3406], should be
replaced by references to this document. replaced by references to this document.
We would appreciate a reorganization of the Registry web page to make We would appreciate a reorganization of the Registry web page to make
the registration templates for Informal URN Namespaces directly the registration templates for Informal URN Namespaces directly
linked from the main page; this would make the page /assignments/ linked from the main page; this would make the page /assignments/
urn-informal.htm page dispensable (for persistency's sake, the web urn-informal.htm page dispensable (for persistency's sake, the web
server should redirect requests to the /assignments/urn-namespaces server should redirect requests to the /assignments/urn-namespaces
page. page.
Section 4 of this document outlines the general procedures. Section 4 of this document outlines the general procedures. Sections
Section 4.4.4 above describes the syntax rules for NIDs to which the 4.2 and 4.3 above describe the syntax rules for NIDs to which the
registry needs to obey. registry needs to obey.
As pointed out in Section 4.4.4 above and in RFC 2141bis As pointed out in Section 4.3 above and in RFC 2141bis
[I-D.ietf-urnbis-rfc2141bis-urn], the string "urn" is permanently [I-D.ietf-urnbis-rfc2141bis-urn], the string "urn" is permanently
reserved and MUST NOT be assigned as an NID. All strings starting reserved and MUST NOT be assigned as an NID. All strings starting
with "example" are permanently reserved for use in code and with "example" are permanently reserved for use in code and
documentation, and hence MUST NOT be assigned as an NID. documentation, and hence MUST NOT be assigned as an NID.
In all cases of new Namespace registration proposals, the IANA should In conformance with BCP 100 [RFC4020], in all cases of new Namespace
provisionally assign the appropriate NID (informal or formal), as registration proposals, the IANA should provisionally assign the
described throughout the body of this memo, once an IESG-designated appropriate NID (informal or formal), as described throughout the
expert has confirmed that the requisite registration process steps body of this memo, once an IESG-designated expert has confirmed that
have been completed. These registrations become permanent and can be the requisite registration process steps have been completed. These
made publicly available once the registration document has been registrations become permanent and can be made publicly available
approved by the IESG for publications as a Standards-Track or once the registration document has been approved by the IESG for
Informational RFC. 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 7. Acknowledgements
This document is heavily based on RFC 3406, the authors of which are This document is heavily based on RFC 3406 (and thereby its
cordially acknowledged. 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 This document also been inspired by other recent documents that have
updated important IANA registries, and the countless authors and updated important IANA registries, and the countless authors and
contributors to these efforts are acknowledged anonymously. contributors to these efforts are acknowledged anonymously.
Several individuals in the URNbis working group have participated in Several individuals in the URNbis working group have participated in
the detailed discussion of this memo. Particular thanks for detailed the detailed discussion of this memo. Particular thanks for detailed
review comments and text suggestions go to Juha Hakala, Peter Saint- review comments and text suggestions go to (in alphabetical order)
Andre, and Mykyta Yevstifeyev. Leslie Daigle Juha Hakala, Subramanian Moonesamy. Peter Saint-Andre,
Lars Svensson, and Mykyta Yevstifeyev.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-urnbis-rfc2141bis-urn] [I-D.ietf-urnbis-rfc2141bis-urn]
Hoenes, A., "Uniform Resource Name (URN) Syntax", Hoenes, A., "Uniform Resource Name (URN) Syntax",
draft-ietf-urnbis-rfc2141bis-urn-02 (work in progress), draft-ietf-urnbis-rfc2141bis-urn-03 (work in progress),
March 2012. October 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
8.2. Informative References 8.2. Informative References
[IANA] IANA, "The Internet Assigned Numbers Authority", [IANA] IANA, "The Internet Assigned Numbers Authority",
<http://www.iana.org/>. <http://www.iana.org/>.
[IANA-URN] IANA, "Uniform Resource Names (URN) Namespace Registry", [IANA-URN]
IANA, "Uniform Resource Names (URN) Namespace Registry",
<http://www.iana.org/assignments/urn-namespaces/>. <http://www.iana.org/assignments/urn-namespaces/>.
[RFC2276] Sollins, K., "Architectural Principles of Uniform Resource [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource
Name Resolution", RFC 2276, January 1998. Name Resolution", RFC 2276, January 1998.
[RFC2611] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, [RFC2611] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"URN Namespace Definition Mechanisms", BCP 33, RFC 2611, "URN Namespace Definition Mechanisms", BCP 33, RFC 2611,
June 1999. June 1999.
[RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/ [RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/
IETF URI Planning Interest Group: Uniform Resource IETF URI Planning Interest Group: Uniform Resource
Identifiers (URIs), URLs, and Uniform Resource Names Identifiers (URIs), URLs, and Uniform Resource Names
(URNs): Clarifications and Recommendations", RFC 3305, (URNs): Clarifications and Recommendations", RFC 3305,
August 2002. August 2002.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS", RFC 3401, October 2002. Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS) [RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Five: URI.ARPA Assignment Procedures", BCP 65, Part Five: URI.ARPA Assignment Procedures", BCP 65,
RFC 3405, October 2002. RFC 3405, October 2002.
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition "Uniform Resource Names (URN) Namespace Definition
Mechanisms", BCP 66, RFC 3406, October 2002. Mechanisms", BCP 66, RFC 3406, October 2002.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
July 2003. July 2003.
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
Standards Track Code Points", BCP 100, RFC 4020,
February 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
Appendix A. URN Namespace Definition Template Appendix A. URN Namespace Definition Template
Definition of a URN Namespace is accomplished by completing the Definition of a URN Namespace is accomplished by completing the
following information template. following information template. It is provided in two versions; the
annotated template with comments explaining what should go into the
filled-out template is shown in Appendix A.1 and the plain template
that can be used as a starting point for filling in the required
information via plaintext editing is shown in Appendix A.2.
To further the application of the template, both forms will be made
available in xml2rfc form on the IETF Tools and/or IANA web site [[
to be decided ]].
In case of (unintended) deviations, Appendix A.1 takes precedence
over Appendix A.2.
Apart from providing a mechanism for disclosing the structure of the Apart from providing a mechanism for disclosing the structure of the
URN Namespace, this information is designed to be useful for URN Namespace, this information is designed to be useful for
- entities seeking to have a URN assigned in a Namespace (if - entities seeking to have a URN assigned in a Namespace (if
applicable) and applicable) and
- entities seeking to provide URN resolvers for a Namespace (if - entities seeking to provide URN resolvers for a Namespace (if
applicable). 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 Applications for Formal URN Namespaces must also document "Namespace
Considerations", "Community Considerations", "Security Considerations", "Community Considerations", "Security
Considerations", and "IANA Considerations", as described in Considerations", and "IANA Considerations", as described in
Section 4.4. Section 4.4.
Information in the template is as follows (text in curly braces is A.1. Annotated URN Namespace Definition Template
tutorial and should be removed from filled-in templates):
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: Namespace ID:
{ If request is for an Informal NID, indicate so; the number will { If request is for an Informal NID, indicate so; the number will
be assigned by IANA. In the case of a Formal NID registration, be assigned by IANA. In the case of a Formal NID registration,
regularly a particular NID string will be requested. } regularly a particular NID string will be requested. }
Kind of named resources:
{ Short description of what resources are named under this NID. }
Registration Information: Registration Information:
{ This is information to identify the particular version of { This is information to identify the particular version of
registration information: } registration information: }
- version number: - version number:
{ starting with 1, incrementing by 1 with each new version } { starting with 1, incrementing by 1 with each new version }
- date: - date:
{ date submitted to the IANA or date of approval of { date submitted to the IANA or date of approval of
registration document, using the format outlined in "Date and registration document, using the format outlined in "Date and
Time on the Internet: Timestamps", [RFC3339]: YYYY-MM-DD } Time on the Internet: Timestamps", [RFC3339]: YYYY-MM-DD }
skipping to change at page 19, line 34 skipping to change at page 22, line 28
- Registering organization: - Registering organization:
Name: { ... } Name: { ... }
Address: { ... } Address: { ... }
- Designated contact person: - Designated contact person:
Name: { ... } Name: { ... }
{ Address: ... { Address: ...
(at least one of: Email, Phone, Postal address) } (at least one of: Email, Phone, Postal address) }
Declaration of syntactic structure of NSS part: Declaration of syntactic structure of NSS part:
{ Note: In the past, there has been iterated trouble in tentative
registration documents with confusion between entire URN syntax
and NSS syntax (only). Since the "urn:" prefix is fixed and the
NID is fully determined by the "Namespace ID" clause above, in
order to avoid error prone duplication, this version of the
template restricts this clause to the NSS (Namespace Specific
String) part of the new URNs. }
{ {
This section should outline any structural features of identifiers This clause should outline any structural features of identifiers
in this Namespace. At the very least, this description may be in this Namespace. At the very least, this description may be
used to introduce terminology used in other sections. This used to introduce terminology used in other clauses. This
structure may also be used for determining realistic caching/ structure may also be used for determining realistic caching/
shortcuts approaches; suitable caveats should be provided. If shortcuts approaches; suitable caveats should be provided. If
there are any specific character encoding rules (e.g., which there are any specific character encoding rules (e.g., which
character should always be used for single-quotes), these should character should always be used for single-quotes), these should
be listed here. be listed here.
Answers might include, but are not limited to: Answers might include, but are not limited to:
- the structure is opaque (no exposition); - the structure is opaque (no exposition);
- a regular expression for parsing the identifier into - a regular expression for parsing the identifier into
components, including naming authorities; components, including naming authorities;
- formal syntax of the NSS, preferably in ABNF (STD 68 - formal syntax of the NSS, preferably in ABNF (STD 68
[RFC5234]). [RFC5234]).
} }
Relevant ancillary documentation: Relevant ancillary documentation:
{ {
This section should list any RFCs, standards, or other published This clause should list any RFCs, standards, or other published
documentation that defines or explains all or part of the documentation that defines or explains all or part of the
namespace structure. namespace structure.
Answers might include, but are not limited to: Answers might include, but are not limited to:
- RFCs that outline the syntax of the namespace; - RFCs that outline the syntax of the namespace;
- other documents of the defining community (e.g., ISO) that - other documents of the defining community (e.g., ISO) that
outline the syntax of the identifiers in the namespace; outline the syntax of the identifiers in the namespace;
- explanatory material that introduces the namespace. - explanatory material that introduces the namespace.
} }
Conformance with URN Syntax: Conformance with URN Syntax:
{ {
This section should outline any special considerations required This clause should outline any special considerations required for
for conforming with the URN syntax. This is particularly conforming with the URN syntax. This is particularly applicable
applicable in the case of legacy naming systems that are used in in the case of legacy naming systems that are used in the context
the context of URNs. of URNs.
For example, if a namespace is used in contexts other than 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. it may make use of characters that are reserved in the URN syntax.
This section should flag any such characters, and outline This clause should flag any such characters, and outline necessary
necessary mappings to conform to URN syntax. Normally, this will mappings to conform to URN syntax. Normally, this will be handled
be handled by percent-encoding the symbol. by percent-encoding the symbol.
} }
Rules for Lexical Equivalence of NSS part: Rules for Lexical Equivalence of NSS part:
{ Note: In the past, there has been iterated trouble in tentative
registration documents with regard to what rules can be imposed
for lexical equivalence. Since the "urn:" prefix and the NID part
both are invariably case-insensitive per RFC 3986 and RFC 2141bis,
in order to avoid repeated confusion, this version of the template
tentatively restricts this clause to only the NSS part of the
newly specified URNs. }
{ {
If there are particular algorithms for determining equivalence If there are particular algorithms for determining equivalence
between two identifiers in the underlying namespace (and hence, in between two identifiers in the underlying namespace (and hence, in
the URN string itself), rules can be provided here. the URN string itself), rules can be provided here.
Some examples include: Some examples include:
- equivalence between hyphenated and non-hyphenated groupings in - equivalence between hyphenated and non-hyphenated groupings in
the identifier string; the identifier string;
- equivalence between single-quotes and double-quotes; - equivalence between single-quotes and double-quotes;
- namespace-defined equivalences between specific characters, - namespace-defined equivalences between specific characters,
skipping to change at page 21, line 37 skipping to change at page 24, line 14
screening operation performed by applications that try to remain screening operation performed by applications that try to remain
as general as possible and typically will not have built-in, NID- as general as possible and typically will not have built-in, NID-
specific knowledge -- ultimately, functional (or semantical) specific knowledge -- ultimately, functional (or semantical)
equivalence of URNs can only be decided in the NID-specific equivalence of URNs can only be decided in the NID-specific
assignment/resolution systems, and their internal rules can be assignment/resolution systems, and their internal rules can be
handled much more flexibly than more complicated, nailed-down handled much more flexibly than more complicated, nailed-down
lexical equivalence rules that are unlikely to be implemented at lexical equivalence rules that are unlikely to be implemented at
large. 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: Identifier uniqueness considerations:
{ {
This section should address the requirement that URN identifiers This clause should address the requirement that URN identifiers be
be assigned uniquely -- they are assigned to at most one resource, assigned uniquely -- they are assigned to at most one resource,
and are not reassigned. and are not reassigned.
(Note that the definition of "resource" is fairly broad; for (Note that the definition of "resource" is fairly broad; for
example, information on "Today's Weather" might be considered a example, information on "Today's Weather" might be considered a
single resource, although the content is dynamic.) single resource, although the content is dynamic.)
Possible answers include, but are not limited to: Possible answers include, but are not limited to:
- exposition of the structure of the identifiers, and - exposition of the structure of the identifiers, and
partitioning of the space of identifiers amongst assignment partitioning of the space of identifiers amongst assignment
authorities that are individually responsible for respecting authorities that are individually responsible for respecting
uniqueness rules; uniqueness rules;
- identifiers are assigned sequentially; - identifiers are assigned sequentially;
- information is withheld; that is, the namespace is opaque. - information is withheld; that is, the namespace is opaque.
} }
Identifier persistence considerations: Identifier persistence considerations:
skipping to change at page 22, line 30 skipping to change at page 25, line 30
important in the case of URN Namespaces providing global important in the case of URN Namespaces providing global
resolution. resolution.
Possible answers include, but are not limited to: Possible answers include, but are not limited to:
- quality of service considerations. - quality of service considerations.
} }
Process of identifier assignment: Process of identifier assignment:
{ {
This section should detail the mechanisms and/or authorities for This clause should detail the mechanisms and/or authorities for
assigning URNs to resources. It should make clear whether assigning URNs to resources. It should make clear whether
assignment is completely open, or if limited, how to become an assignment is completely open, or if limited, how to become an
assigner of identifiers, and/or get one assigned by existing assigner of identifiers, and/or get one assigned by existing
assignment authorities. assignment authorities.
Answers could include, but are not limited to: Answers could include, but are not limited to:
- assignment is completely open, following a particular - assignment is completely open, following a particular
algorithm; algorithm;
- assignment is delegated to authorities recognized by a - assignment is delegated to authorities recognized by a
particular organization (e.g., the Digital Object Identifier particular organization (e.g., the Digital Object Identifier
Foundation controls the DOI assignment space and its Foundation controls the DOI assignment space and its
delegation); delegation);
- assignment is completely closed (e.g., for a private - assignment is completely closed (e.g., for a private
organization). organization).
} }
Process for identifier resolution: 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, If a Namespace is intended to be accessible for global resolution,
it must be registered in an RDS (Resolution Discovery System, see it must be registered in an RDS (Resolution Discovery System, see
RFC 2276 [RFC2276]) such as the DDDS (see RFC 3401 [RFC3401]). RFC 2276 [RFC2276]) such as the DDDS (see RFC 3401 [RFC3401]).
Resolution then proceeds according to standard URI resolution Resolution then proceeds according to standard URI resolution
processes, and the mechanisms of the RDS. What this section processes, and the mechanisms of the RDS. What this clause should
should outline is the requirements for becoming a recognized outline is the requirements for becoming a recognized resolver of
resolver of URNs in this Namespace (and being so listed in the RDS URNs in this Namespace (and being so listed in the RDS registry).
registry).
Answers may include, but are not limited to: Answers may include, but are not limited to:
- the Namespace is not listed with an RDS, this is not relevant; - the Namespace is not listed with an RDS, this is not relevant;
- resolution mirroring is completely open, with a mechanism for - resolution mirroring is completely open, with a mechanism for
updating an appropriate RDS; updating an appropriate RDS;
- resolution is controlled by entities to which assignment has - resolution is controlled by entities to which assignment has
been delegated. been delegated.
} }
Validation mechanism: Validation mechanism:
skipping to change at page 24, line 8 skipping to change at page 27, line 8
Validation mechanisms might be: Validation mechanisms might be:
- a syntax grammar; - a syntax grammar;
- an on-line service; - an on-line service;
- an off-line service. - an off-line service.
} }
Scope: Scope:
{ {
This section should outline the scope of the use of the This clause should outline the scope of the use of the identifiers
identifiers in this namespace, i.e. the precise kind of resources in this namespace, i.e. the precise kind of resources to which the
to which the URNs are assigned. Apart from considerations of URNs are assigned. Apart from considerations of private vs.
private vs. public namespaces, this section is critical in public namespaces, this clause is critical in evaluating the
evaluating the applicability of a requested NID. For example, a applicability of a requested NID. For example, a namespace
namespace claiming to deal with "social security numbers" should claiming to deal with "social security numbers" should have a
have a global scope and address all social security number global scope and address all social security number structures
structures (unlikely). On the other hand, at a national level, it (unlikely). On the other hand, at a national level, it is
is reasonable to propose a URN Namespace for "this nation's social reasonable to propose a URN Namespace for "this nation's social
security numbers". security numbers".
} }
Appendix B. Registration steps in practice 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 The key steps for registration of Informal or Formal Namespaces
typically play out as follows: typically play out as follows:
A) Informal NID: A) Informal NID:
1. Complete the registration template. This may be done as part 1. Complete the registration template. This may be done as part
of an Internet-Draft. of an Internet-Draft.
2. Communicate the registration template to urn-nid@ietf.org for 2. Communicate the registration template to urn-nid@ietf.org for
skipping to change at page 25, line 24 skipping to change at page 29, line 24
(submitted as I-D revisions) and/or direct discussion to (submitted as I-D revisions) and/or direct discussion to
designated working groups, area experts, etc. designated working groups, area experts, etc.
5. The IESG evaluation process includes a review by IANA, and if 5. The IESG evaluation process includes a review by IANA, and if
the IESG approves the document for publication as an RFC, IANA the IESG approves the document for publication as an RFC, IANA
processing of the document will follow the regular work-flow processing of the document will follow the regular work-flow
between the RFC Editor and IANA. This way, the NID between the RFC Editor and IANA. This way, the NID
registration will be made public by IANA when the RFC is registration will be made public by IANA when the RFC is
published. published.
Appendix C. Changes from RFC 3406 Appendix C. Changes from RFC 3406 (Informative)
C.1. Essential Changes since RFC 3406 C.1. Essential Changes since RFC 3406
[ RFC Editor: please remove the Appendix C.1 headline and all [ RFC Editor: please remove the Appendix C.1 headline and all
subsequent subsections of Appendix C starting with Appendix C.2. ] subsequent subsections of Appendix C starting with Appendix C.2. ]
T.B.D. (after consolidation of this memo) [[ T.B.D. in next iteration of this memo. ]]
C.2. Changes from RFC 3406 to URNbis WG Draft -00 C.2. Changes from RFC 3406 to URNbis WG Draft -00
o Abstract: rewritten entirely; o Abstract: rewritten entirely;
o Section 1 (Introduction): added historical RFC information; o Section 1 (Introduction): added historical RFC information;
o Section 1.1 (Requirements Language): added; o Section 1.1 (Requirements Language): added;
o Section 3.1: added Note that challenges the utility of o Section 3.1: added Note that challenges the utility of
skipping to change at page 28, line 48 skipping to change at page 32, line 48
equivalence of URNs, with the caveats that such things are rather equivalence of URNs, with the caveats that such things are rather
unlikely to get traction in general-purpose client software. unlikely to get traction in general-purpose client software.
Removed historical Appendix B.1 (Example Template). Removed historical Appendix B.1 (Example Template).
Various editorial enhancements and fixes. Various editorial enhancements and fixes.
Updated and expanded "Issues" Appendix (below) in preparation of Updated and expanded "Issues" Appendix (below) in preparation of
usage of the IETF Issue Tracker. usage of the IETF Issue Tracker.
Appendix D. Issues in this Draft C.5. Changes from URNbis WG I-D -02 to -03
[ Appendix to be replaced by use of IETF Tools issue tracker. ] Due to the scattered discussion of the previous draft version, the
items below not only list effected changes but also give rationale
for where suggested changes have not been applied.
For more details on the issues below, please also see the Editorial Document title shortened to better reflect entire purpose of
Notes interspersed in the body of this draft. document.
Discuss consequences of RFC 2141bis (once consensus is achieved); if Abstract: revised and shortened (comments from SM).
proposal for fragment part is adopted, details need to be described
per Namespace that wants to adopt these possibilities, and maybe the
registration template needs a new clause where this will be specified
-- or the information has to be assigned to existing clauses.
Do registration documents need more guidance and be caused to be more Introduction:
precise in their elaboration on the applicability of Services? Since Rephrased 1st para to put emphasis on name binding property (derived
RFC 2483 is considered outdated, but RFC 2483bis not yet alife (nor a from list discussion on related topic, Keith Moore et al.).
URNbis work item), we might need a registry for URN Services Amended / modified text to better reflect the intended audience of
(initially populated from RFC 2483) that can be referred to in the memo and its contents, and to accommodate the evolution of the
Namespace registration documents, thus avoiding normative rfc2141bis I-D.
dependencies on a future RFC 2483bis. 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.
Do we actually need Experimental Namespaces? Section 2:
[Regarded as CLOSED affirmatively at IETF 80.] Amended by text describing the 3 methods available to Namespace
There are concerns regarding usage of "X-" NIDs, which is reported to designers / stakeholdes to make component resources of structured
having proven impractical in practice. This draft version contains resources identifiable/accessible.
tentative text to address these concerns; "X-" is now demoted to Some existing text reworded based on comments (SM et al.).
"SHOULD" level. 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.)
The syntax of the NID strings for the various NID types is given in s3.3: Reworded "benefit" clause to clarify distinction between the
an informal manner (as has been done in RFC 3406); is it worth the community interested in a new Namespace and the Internet community at
effort to introduce ABNF for this purpose? large (corollary to comments on and revision of s4.4.2.).
[The request for ABNF has been voiced only once; the document Editor
regards this issue as CLOSED.]
Increase review/timeout periods for urn-nid list and IANA experts s4: (dealing with comments from SM, PSA)
from 2 to 4 (or more) weeks? This draft version tentatively The justification for the need to consider and specify registration
specifies 4 weeks. maintenance procedures has been in RFC 3406; the text from there has
Juha Hakala has argued that the assessment of the responsible been updated according to our chartered, to update for RFC 5226.
organizations needed to assure their ability to properly operate the This matter needs to be taken into account by prospective Namespace
Namespace could never be performed within the present 2 weeks time owners, and thus the text makes sense in this document.
span; 8 weeks might be an even better choice for the future upper Reorganization of subsequent text made it logically necessary to
limit for the review period. It has been pointed out that even 8 include into this section a high level description of the
weeks are miniscule with regard to the expected lifetime of the to- urn-nid@ietf.org list. The nominal review period is left a four
be-registered Namespace and hence should not matter. In practice, weeks in this draft revision, but a Note has been added to s4
the subsequent IESG evaluation of URN Namespace registration indicating that this is an upper limit to accommodate headroom,
documents has typically needed much longer time. 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.
Clarification of the desired content of the "Namespace s4.1: No technical changes. The continued use of the "X-" prefix for
Considerations" and "Community Considerations" sections in Experimental Namespaces does not violate RFC 6648 because this is
registration documents. Shall we admit a combined section for both legacy practice, experimental NIDs are not being registered, and this
topics? (so far supported by 2 postings) Cf. the NOTEs in Sections memo again prohibits the use of Experimental Namespaces in the open
4.4.1 and 4.4.2 for more details. Internet.
[No feedback on the list since -01, so the draft text seems to have
silent consensus and the issue is regarded as CLOSED.]
Shall other strings beyond "urn" also be 'reserved' in the NID
registry? (e.g. "uri", "url", "urc", ...) There have been voices in
favor of leaving the decision of what is acceptable and reasonable in
practice to the common sense of prospective registrants and the
designated IANA experts. This draft version reserves NID strings
matching the RE "^example.*" for documentation.
Appendix A: Once RFC 2483 gets updated and an IANA registry for URN s4.3:
resolution services gets established, the "Process for identifier Text reorganized, incorporating material from s4.4.4 (see below).
resolution" clause in the registration template should call out for The text on the (modified) "IETF Review" policy has been upgraded
enumerating the registered services that are applicable for the newly from RFC 3406 (and thereby effectively shortened). It serves to give
defined URN Namespace. concise information to the expected primary audience of the document,
How far can we go in this respect without an update to RFC 2483 at applicants for Namespaces, which according to experience are rather
hands? 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.
Do we really still need Appendix B.1 ? (There are lots of real-life s4.4: text amended to avoid confusion about registration template.
examples now!)
[ Old B.1 removed, old B.2 became Appendix B; ==> CLOSED ] s4.4.1 and s4.4.2: Heavily reworked based on discussion (Leslie, PSA,
Juha, et al.). Bullet lists now point to clauses of the registration
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
sentences and gives the appropriate reference (to BCP 72); hence it
is regarded as non-disposable -- no change.
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
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
formal namespaces was intended as a checklist for IANA; following
comments from Lars Svensson, it has been moved from s4.4.4 to s4.3
and related text has been modified accordingly.
s4.4.4: substantially revised (comments from Lars Svensson et al.).
IANA Cons. (s6): Added request to IANA to clarify the procedures for
Formal NIDs in the list of ptorocol parameter registries.
Updated and expanded Acknowledgements.
References: RFC 3339 demoted to Informational; you don't need to read
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.
Appendix A:
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.
Modified title of App. B, declared it Informative.
This Appendix C.5 added; previous Appendix D (Issues) dropped.
Multiple editorial fixes and enhancements.
Author's Address Author's Address
Alfred Hoenes Alfred Hoenes (editor)
TR-Sys TR-Sys
Gerlinger Str. 12 Gerlinger Str. 12
Ditzingen D-71254 Ditzingen D-71254
Germany Germany
EMail: ah@TR-Sys.de EMail: ah@TR-Sys.de
 End of changes. 99 change blocks. 
394 lines changed or deleted 661 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/