draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt   draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt 
IETF URNbis WG A. Hoenes IETF URNbis WG A. Hoenes
Internet-Draft TR-Sys Internet-Draft TR-Sys
Obsoletes: 3406 (if approved) October 31, 2011 Obsoletes: 3406 (if approved) March 12, 2012
Intended status: BCP Intended status: BCP
Expires: May 3, 2012 Expires: September 13, 2012
Uniform Resource Name (URN) Namespace Definition Mechanisms Uniform Resource Name (URN) Namespace Definition Mechanisms
draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02
Abstract Abstract
Uniform Resource Names (URNs) are intended to serve as persistent, Uniform Resource Names (URNs) are intended to serve as persistent,
location-independent, resource identifiers. To structure and location-independent, resource identifiers. To structure and
organize their usage, the URN syntax specifies a hierarchy that organize their usage, the URN syntax (RFC 2141bis) specifies a
divides the set of possible URNs into "URN Namespaces" that can be hierarchy that divides the set of possible URNs into "URN Namespaces"
individually defined and managed. URN Namespaces in particular serve that can be individually defined and managed. URN Namespaces in
to map existing identifier systems into the URN system and thereby particular serve to map existing identifier systems into the URN
make available generic, network-based resolution services for the system and thereby make available generic, network-based resolution
identified documents, artifacts, and other objects (and their services for the identified documents, artifacts, and other objects
metadata). (and metadata related to them).
To actually leverage such synergetic advantage, URN Namespaces need To achive these goals, URN Namespaces need to be specified in a
to be specified in a comparable manner, and their Namespace comparable manner, and their Namespace Identifiers (NIDs) need to be
Identifiers (NIDs) need to be registered with IANA, so that naming registered with IANA, so that naming conflicts are avoided and
conflicts are avoided and implementers of services can follow a implementers of services can follow a structured approach in support
structured approach in support of various namespaces, guided by the of various namespaces, guided by the registry to the related
registry to the related documents and the particularities of specific documents and the particularities of specific namespaces, as
namespaces, as described in these namespace registration documents. described in these Namespace registration documents.
This document serves as a guideline for authors of URN Namespace This RFC serves as a guideline for authors of URN Namespace
definition and registration documents. It describes the essential definition and registration documents and the process to be followed
to register a URN Namespace with IANA. It describes the essential
content of such documents and how they shall be structured to allow content of such documents and how they shall be structured to allow
readers familar with the scheme to quickly assess the properties of a readers familar with the scheme to quickly assess the properties of a
specific URN Namespace. Further, this RFC describes the process to specific URN Namespace.
be followed to get a URN Namespace registered with IANA.
This document is a companion document to the revised URN Syntax This document is a companion document to the revised URN Syntax
specification, RFC 2141bis; it 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.
Status of This Memo Status of This Memo
skipping to change at page 2, line 15 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirement Language . . . . . . . . . . . . . . . . . . . 5 1.1. Requirement Language and Terminology . . . . . . . . . . . 5
2. What is a URN Namespace? . . . . . . . . . . . . . . . . . . . 5 2. What is a URN Namespace? . . . . . . . . . . . . . . . . . . . 5
3. URN Namespace (Registration) Types . . . . . . . . . . . . . . 6 3. URN Namespace (Registration) Types . . . . . . . . . . . . . . 7
3.1. Experimental Namespaces . . . . . . . . . . . . . . . . . 6 3.1. Experimental Namespaces . . . . . . . . . . . . . . . . . 7
3.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 6 3.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 7
3.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 7 3.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 7
4. URN Namespace Registry: Processes for Registration and 4. URN Namespace Registry: Processes for Registration and
Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Experimental Namespaces: No Registration . . . . . . . . . 9 4.1. Experimental Namespaces: No Registration . . . . . . . . . 10
4.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 9 4.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 10
4.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 10 4.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 11
4.4. Registration Documents . . . . . . . . . . . . . . . . . . 11 4.4. Registration Documents . . . . . . . . . . . . . . . . . . 12
4.4.1. Namespace Considerations in Registration Documents . . 11 4.4.1. Namespace Considerations in Registration Documents . . 12
4.4.2. Community Considerations in Registration Documents . . 12 4.4.2. Community Considerations in Registration Documents . . 13
4.4.3. Security Considerations in Registration Documents . . 12 4.4.3. Security Considerations in Registration Documents . . 14
4.4.4. IANA Considerations in Registration Documents . . . . 13 4.4.4. IANA Considerations in Registration Documents . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. URN Namespace Definition Template . . . . . . . . . . 16 Appendix A. URN Namespace Definition Template . . . . . . . . . . 18
Appendix B. Illustration . . . . . . . . . . . . . . . . . . . . 22 Appendix B. Registration steps in practice . . . . . . . . . . . 24
B.1. Example Template . . . . . . . . . . . . . . . . . . . . . 22
B.2. Registration steps in practice . . . . . . . . . . . . . . 24
Appendix C. Changes from RFC 3406 . . . . . . . . . . . . . . . . 25 Appendix C. Changes from RFC 3406 . . . . . . . . . . . . . . . . 25
C.1. Essential Changes since RFC 3406 . . . . . . . . . . . . . 25 C.1. Essential Changes since RFC 3406 . . . . . . . . . . . . . 25
C.2. Changes from RFC 3406 to URNbis WG Draft -00 . . . . . . . 25 C.2. Changes from RFC 3406 to URNbis WG Draft -00 . . . . . . . 25
Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . . 28 C.3. Changes from URNBIS WG I-D -00 to -01 . . . . . . . . . . 28
C.4. Changes from URNBIS WG I-D -01 to -02 . . . . . . . . . . 28
Appendix D. Issues in this Draft . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Uniform Resource Names (URNs) are resource identifiers with the Uniform Resource Names (URNs) are resource identifiers adhering to
specific requirements for enabling location-independent the specific requirements of enabling location-independent
identification of a resource, as well as longevity of reference. identification of a resource, as well as longevity of reference.
URNs are part of the larger Uniform Resource Identifier (URI) family URNs are part of the larger Uniform Resource Identifier (URI) family
(see the joint W3C/IETF memorandum, RFC 3305 [RFC3305], and the IETF (see the joint W3C/IETF memorandum, RFC 3305 [RFC3305], and the IETF
STD 66, RFC 3986 [RFC3986]) with the specific goal of providing STD 66, RFC 3986 [RFC3986]) with the specific goal of providing
persistent naming of resources. persistent naming of resources.
The URN Syntax (see below and RFC 2141bis
[I-D.ietf-urnbis-rfc2141bis-urn]) structures and organizes the
entirety of URNs into a hierarchy that divides the set of possible
URNs into "URN Namespaces" that can be individually defined, managed,
and (optionally) further subdivided. URN Namespaces in particular
serve to map existing identifier systems into the URN system and
thereby make available generic, network-based resolution services for
the identified documents, artifacts, 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 Namespaces (per the URN
syntax definition) are valid URN Namespaces. A URN Namespace must syntax definition) are valid URN Namespaces. A URN Namespace must
have a recognized definition in order to be valid. have a recognized definition in order to be valid.
To actually leverage the potential synergetic advantage of this
unification (structured embedding of existing namespaces into the URN
framework), URN Namespaces need to be specified in a comparable
manner, and their Namespace Identifiers (NIDs) need to be centrally
registered, so that naming conflicts are avoided and implementers of
services can follow a structured approach in support of various
namespaces, guided by the registry to the related documents and the
particularities of specific namespaces, as described in these
Namespace registration documents.
The purpose of this document is to outline a mechanism and provide a The purpose of this document is to outline a mechanism and provide a
template for explicit namespace definition, as well as provide the template for explicit URN Namespace definition, as well as provide
mechanism for associating an identifier (called a "Namespace ID", or the mechanism for associating an identifier (called a "Namespace ID",
NID), which is registered with the Internet Assigned Numbers or NID), which is registered with the Internet Assigned Numbers
Authority (IANA) [IANA] in the URN Namespaces registry maintained at Authority (IANA) [IANA] in the URN Namespaces registry maintained at
[IANA-URN]. [IANA-URN].
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 RFC 2611 [RFC2611], which has been obsoleted
by BCP 66, RFC 3406 [RFC3406]. Guidelines for documents prescribing by BCP 66, RFC 3406 [RFC3406]. Guidelines for documents prescribing
IANA procedures have been revised as well over the years, and at the IANA procedures have been revised as well over the years, and at the
time of this writing, BCP 26, RFC 5226 [RFC5226] is the normative time of this writing, BCP 26, RFC 5226 [RFC5226] is the normative
document. This document is a revision of RFC 3406 based on the document. This document is a revision of RFC 3406 based on the
revised URN Syntax specification RFC 2141bis revised URN Syntax specification 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
provided 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. directory. There also is work in progress [Ref: t.b.d.] to establish
an IANA registry for URN services, such that registration documents
can unambiguously identify such services and discuss their
applicability to the particular URN Namespace.
1.1. Requirement Language 1.1. Requirement Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
In this document, these key words describe requirements for the In this document, these key words describe requirements for the
process to be followed and the content to be provided in namespace process to be followed and the content to be provided in URN
definition documents and registration templates. 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 lowercase, 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 1 resource, nor are they ever re-assigned to a different to more than one resource. These resources may be stable (e.g., a
resource. A single resource, however, may have more than one URN doctoral dissertation or an abstract concept of a protocol) or
assigned to it for different purposes. Such namespace might be dynamic (e.g., a continuously evolving web site of a periodical or a
defined by some pre-established (standard or non-standard) identifier specific protocol parameter registry subject to additions and
system that can be made "network-actionable" by embedding it into the maintenance). If the identified resource is a metadata record, such
URN framework using a specific URN Namespace. A URN Namespace itself record may describe several objects (such as two versions of a book)
has an identifier in order to: or a collection of objects (such as a periodical with, say, monthly
issues); in this case, these subordinate objects are not the
identified resources. For each namespace, it must be clear what the
identified resources are; if the namespace is heterogenous in this
respect, the registration and resolution systems must unambiguously
designate the kind of identified resource, for each identifier
assigned in the namespace. Once assigned, URNs are never re-assigned
to a different resource. A single resource, however, may have more
than one URN assigned to it -- within a particular Namespace or among
different Namespaces -- for different purposes, since the Namespaces
are not mutually exclusive.
Such abstract namespace might be defined by some pre-established
(standard or non-standard) identifier system that can be made
"network-actionable" by embedding it into the URN framework using a
specific URN Namespace. A URN Namespace itself has an identifier in
order to:
- ensure global uniqueness of URNs, - ensure global uniqueness of URNs,
- (where desired) provide a cue for the structure of the identifier. - (where desired) provide a cue for the structure of the identifier.
For example, many identifier systems use strings of numbers as For example, many identifier systems use strings of numbers as
identifiers (e.g., ISBN, ISSN, phone numbers). It is conceivable identifiers (e.g., ISBN, ISSN, phone numbers). It is conceivable
that there might be some numbers that are valid identifiers in two that there might be some numbers that are valid identifiers in two
different established identifier systems. Using different different established identifier systems. Using different
designators for the two collections ensures that no two URNs will be designators for the two collections (and making these designators an
intrinsic syntactic part of URNs) ensures that no two URNs will be
the same for different resources (since each collection is required the same for different resources (since each collection is required
to uniquely assign each identifier). to uniquely assign each identifier).
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, etc.); they are beyond the scope of the IETF URN protocol developers, technology-specific vendor groups, etc.); they
work. are beyond the scope of the IETF URN work.
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 of URN Namespaces defined here, There are three categories (types) of URN Namespaces defined here,
distinguished by expected level of service and required procedures distinguished by expected level of service and required procedures
for registration. Registration processes for each of these namespace for registration. Registration processes for each of these Namespace
types are given in Section 4. types are given in Section 4. In both this Section and Section 4
these categories are ordered by increasing relevance/importance for
the Internet and, accordingly, increasing strenght of requirements
for the definition and registration processes.
3.1. Experimental Namespaces 3.1. Experimental Namespaces
These are not explicitly registered with IANA. These are not explicitly registered with IANA.
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. However, as described below in Section 4.1, these are contexts. However, as described below in Section 4.1, these are
designated by a specific form of the NID to allow differentiation designated by a specific form of the NID to allow differentiation
(without preexisting knowledge of details) from the other URN (without preexisting knowledge of details) from the other URN
Namespace types. Namespace types.
[[ Editorial Note:
Has anybody ever seen usage of such experimental URN Namespaces?
According to the observations of the author, three years of RFC 2611
and nine years of RFC 3406 have constantly seen "tentative grabbing"
and subsequent usage of NIDs that the stakeholders later have tried
to register with IANA as Formal NIDs (with varying success).
So should this kind of namespaces better be dropped and a kind of
provisional NIDs be created? -- This would be in the spirit of BCP
100, RFC 4020 [RFC4020], and it would resemble the manner how URI
Scheme registrations are dealt with (RFC 4395 [RFC4395], [IANA-URI]).
]]
3.2. Informal Namespaces 3.2. Informal Namespaces
These are fully fledged URN Namespaces, with all the rights and These are fully fledged URN Namespaces, with all the rights and
requirements associated thereto. Informal namespaces can be requirements associated thereto. Informal Namespaces can be
registered in global registration services. They are required to registered in global registration services. They are required to
uphold the general principles of a well-managed URN Namespace -- uphold the general principles of a well-managed URN Namespace --
providing persistent identification of resources and unique providing persistent identification of resources and unique
assignment of identifier strings. Informal and formal namespaces assignment of identifier strings. Informal and Formal Namespaces
(described below) differ in the NID assignment. IANA will assign an (described below) differ in the NID assignment. IANA will assign to
alphanumeric NID (following a defined pattern) to registered informal registered Informal Namespaces a simply structured, alphanumeric,
namespaces, per the process outlined in Section 4. ordinal NID (following a pattern defined in Section 4.2 below), per
the process outlined in Section 4.
3.3. Formal Namespaces 3.3. Formal Namespaces
A formal namespace may be requested, and IETF review sought, in cases A Formal Namespace may be requested, and IETF review sought, in cases
where the publication of the NID proposal and the underlying where the publication of the NID proposal and the underlying
namespace will provide benefit to some subset of users on the namespace will provide benefit to some subset of users on the
Internet. That is, a formal NID proposal, if accepted, must be Internet. That is, a formal NID proposal, if accepted, must be
functional on and with the global Internet, not limited to users in functional on and with the global Internet, not limited to users in
communities or networks not connected to the Internet. For example, communities or networks not connected to the Internet. For example,
assume a NID is requested that is meant for naming of physics assume a NID is requested that is meant for naming of physics
research. If that NID request required that the user use a research material. If that NID request required that the user use a
proprietary network or service that was not at all open to the proprietary network or service that was not at all open to the
general Internet user, then it would make a poor request for a formal general Internet user, then it would make a poor request for a formal
NID. The intent is that, while the community of those who may NID. The intent is that, while the community of those who may
actively use the names assigned within that NID may be small (but no actively use the names assigned within that NID may be small (but no
less important), the potential use of names within that NID is open less important), the potential use of names within that NID is open
to any user on the Internet. to any user on the Internet.
It is expected that Formal NIDs may be applied to namespaces where It is however expected that Formal NIDs may be applied to Namespaces
some aspects are not fully open. For example, a namespace may make where some aspects are not fully open. For example, a Namespace may
use of a fee-based, privately managed, or proprietary registry for make use of a fee-based, privately managed, or proprietary registry
assignment of URNs in the namespace, but it may still provide benefit for assignment of URNs in the Namespace, but it may still provide
to some Internet users if the services associated have openly- benefit to some Internet users if the services associated with it
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 community benefit from formally establishing
the proposed URN Namespace. the proposed URN Namespace.
Additionally, since the goal of URNs is to provide persistent Additionally, since the goal of URNs is to provide persistent
identification, some consideration as to the longevity and identification, careful consideration must be given to the longevity
maintainability of the namespace must be given. The collective and maintainability of the URN Namespace. The collective experience
experience of the IETF community contains a wealth of information on of the IETF community contains a wealth of information on technical
technical factors that will prevent longevity of identification. factors that will prevent longevity of identification. Thus, the
Thus, the IESG may elect not to accept a proposed namespace IESG may elect not to accept a proposed Namespace registration if the
registration if the IETF community consensus is that the registration IETF community consensus is that the registration document contains
document contains technical flaws that will prevent (or seriously technical flaws that will prevent (or seriously impair the
impair the possibility of) persistent identification, and that it possibility of) persistent identification, and that it therefore
therefore should not be published as an RFC. should not be published as an RFC.
In addition to the technical aspects of the namespace and its In addition to the technical aspects of the Namespace and its
resolution, consideration should be given to the following resolution, consideration should be given to the following
organizatorial aspects: organizatorial aspects:
- the organization maintaining the URN Namespace should demonstrate - the organization maintaining the URN Namespace should credibly
stability and the ability to maintain the URN namespace for a long demonstrate stability and the ability to maintain the URN
time, and/or it should be clear how the namespace can continue to Namespace for a long time, and/or it should be clear how the
be usable/useful if the organization ceases to be able to foster Namespace can continue to be usable/useful if the organization
it; ceases to be able to foster it;
- it should demonstrate ability and competency in name assignment; - the organization(s) assigning URNs within the URN Namespace should
this should improve the likelihood of persistence (e.g., to demonstrate ability and competency in name assignment; this should
minimize the likelihood of conflicts); improve the likelihood of persistence (e.g., to minimize the
likelihood of conflicts);
- it needs to commit to not re-assigning existing names and allowing - the organization(s) assigning URNs within the URN Namespace need
old names to continue to be valid, even if the owners or assignees to be committed to honor the scope, rules, and regulations
of those names are no longer members or customers of that outlined its registration document and the documents defining the
organization; this does not mean that there must be resolution of underlying namespace and covering its identifier assignment and
such names, but that they must not resolve the name to false or maintenance procedures (if any), and the organization maintaining
stale information, and that they must not be reassigned. the URN Namespace needs to have procedures in force that aim at
ensuring this adherance at a very high confidence level; and
- the involved organization(s) need to commit to not re-assign
existing names; old names MUST continue to be valid, even if the
owners or assignees of those names are no longer members or
customers of such organization; this does not mean that there
needs to be resolution of such names, but that they must not
resolve such names to false or stale information and that they
must not be reassigned.
If the underlying namespace is based on an established standard, the
standards body or the organization(s) in charge with the maintenance
of the namespace should be involved in the process, either by
performing the registration on their own, or by supporting the action
of the registrant and asserting support of the registration document.
These aspects, though hard to quantify objectively, should be These aspects, though hard to quantify objectively, should be
considered by organizations/people considering the development of a considered by organizations/people considering the development of a
Formal URN Namespace, and they will be kept in mind when evaluating Formal URN Namespace, and they will be kept in mind when evaluating
the technical merits of any proposed Formal URN Namespace. The kind the technical merits of any proposed Formal URN Namespace. The kind
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 (e.g. 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 or may
request a particular identifier. request a particular identifier.
The IANA Considerations Guidelines document (BCP 26, RFC 5226 The IANA Considerations Guidelines document (BCP 26 [RFC5226])
[RFC5226]) suggests the need to specify update mechanisms for suggests the need to specify update mechanisms for registrations --
registrations -- who is given the authority to do so, from time to who is given the authority to do so, from time to time, and what are
time, and what are the processes. Since URNs are meant to be the processes. Since URNs are meant to be persistently useful, few
persistently useful, few (if any) changes should be made to the (if any) changes should be made to the structural interpretation of
structural interpretation of URN strings (e.g., adding or removing URN strings (e.g., adding or removing rules for lexical equivalence
rules for lexical equivalence that might affect the interpretation of that might affect the interpretation of URN IDs already assigned).
URN IDs already assigned). However, it may be important to introduce However, it may be important to introduce clarifications, expand the
clarifications, expand the list of authorized URN assigners, etc., list of authorized URN assigners, etc., over the natural course of a
over the natural course of a namespace's lifetime. Specific Namespace's lifetime. Specific processes are outlined below.
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 maintained by IANA at [IANA-URN].
<http://www.iana.org/assignments/urn-namespaces/>.
The registraty is subdivided into two sub-registries, one for "Formal The registry is subdivided into two sub-registries, one for "Formal
URN Namespaces" and one for "Informal URN Namespaces", and each entry URN Namespaces" and one for "Informal URN Namespaces", and each entry
there links to a stable repository of the registration document or there links to a stable repository of the registration document or
(an escrow copy of) the filled-out registration template. (an escrow copy of) the filled-out registration template.
The registration and maintenance procedures vary slightly between the The registration and maintenance procedures vary slightly between the
namespace types. Namespace types.
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 take the form: registered with IANA. They SHOULD take the form:
X-<nid> X-<nid>
where <nid> is a string consisting solely of letters, decimal digits, where <nid> is a string of up to 30 characters, consisting solely of
and hyphen ("-") characters, as specified by the NID syntax letters, decimal digits, and hyphen ("-") characters, as specified by
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
accommodate experience and demonstrated evidence that, under
specific circumstances, experimental prototype systems have to
create and assign identifiers that the interested community
perceives are infeasible to be changed once the Namespace gets
formally registered. However, it is strongly RECOMMENDED to
prefix eventually targeted NIDs by "X-" during experiments and
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 and registered in their own sub-registry, as
indicated in Section 4; they take the format: 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 two-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.
[[ NOTE: Longer time is needed in practice! Increase to 4 weeks? ]] [[ 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 a NID by email to iana@iana.org .
Registrations may be updated later by the original registrant, or by Registrations may be updated later by the original registrant, or by
an entity designated by the registrant, by updating the registration an entity designated by the registrant, by updating the registration
template, submitting it to the discussion list for a further two-week template, submitting it to the discussion list for a further four-
discussion period, and finally resubmitting it to IANA in a message week discussion period, and finally resubmitting it to IANA in a
to iana@iana.org . 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, as defined in BCP 26
[RFC5226]. The designated expert(s) for URN Namespace registrations [RFC5226]. The designated expert(s) for URN Namespace registrations
are nominated by the IESG, and their role adheres to the regulations are nominated by the IESG, and their role adheres to the regulations
in BCP 26, unless specified otherwise below. in BCP 26, unless specified otherwise below.
NIDs for Formal URN Namespaces MUST NOT have the forms indicated in NIDs for Formal URN Namespaces MUST NOT have the forms indicated in
the preceding two sections for the other two Namespace types. (The the preceding two sections for the other two Namespace types. (The
detailed formal rules are given below in Section 4.4.4.) Applicants, detailed formal rules are given below in Section 4.4.4.) Applicants,
in concert with the IANA experts, should ensure that the sought NID in concert with the IANA experts, should ensure that the sought NID
strings are "proper" for the designated purpose, according to common strings are "proper" for the designated purpose, according to common
sense (and applicable legal rules). sense (and applicable legal rules).
This means that the Formal NID application is made via submission to "IETF Review" (per [RFC5226]) means that the Formal NID application
the IETF of an Internet-Draft that contains the namespace definition is made via submission to the IETF of an Internet-Draft that contains
and targets publication as an RFC of Informational or Standards Track the Namespace definition and targets publication as an RFC of
category, which needs to be approved by the IESG after performing an Informational or Standards-Track category, which needs to be approved
IETF Last Call on the document and evaluating review comments. The by the IESG after performing an IETF Last Call on the document and
applicant can be an individual or an IETF working group, in alignment evaluating review comments. The applicant can be an individual or an
with the designation of the Internet-Draft. It is RECOMMENDED that IETF working group, in alignment with the designation of the
the registration documents for NIDs belonging to an established Internet-Draft. The actual choice should be properly considered by
standard namespace aim at Standards Track, whereas other applications applicants, but it is RECOMMENDED that the registration documents for
aim at Informational. NIDs belonging to an established standard namespace aim at Standards-
Track, whereas other applications aim at Informational RFC.
Before publication can be requested, however, the draft namespace 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 template defined in
Appendix A SHOULD be included as part of an RFC-to-be defining some Appendix A SHOULD be included as part of an RFC-to-be defining some
other aspect(s) of the namespace, or it may be put forward as a other aspect(s) of the Namespace, but it MAY be put forward as a
namespace definition document in its own right. The proposed Namespace definition document in its own right. The proposed
template (including a pointer to a readily available copy of the template (including a pointer to a readily available copy of the
registration document) should be sent to the urn-nid@ietf.org mailing registration document) should be sent to the urn-nid@ietf.org mailing
list for review. This list is monitored by the designated expert(s). list for review. This list is monitored by the designated expert(s).
The applicant has to allow for a four-week discussion period for
The applicant has to allow for a two-week [[ four-week ? ]] clarifying the expression of the registration information, and SHOULD
discussion period for clarifying the expression of the registration improve the Namespace document and/or registration template based on
information, and SHOULD improve the namespace document and/or the comments received, under the guidance of the designated
registration template based on the comments received, under the expert(s), before the IESG reviews the document.
guidance of the designated expert(s), before the IESG reviews the
document.
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, before they hand it over to the IESG,
and individual applicants are also advised to seek expert comments and individual applicants are also advised to seek expert comments
early enough. The aforementioned list can be contacted for informal early enough. The aforementioned list can be contacted for informal
advice at any stage. advice at any stage.
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, which will be focal in the expert
Review process and IETF Review. 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 "Namespace
Considerations" section that outlines the perceived need for a new Considerations" section 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). proposer's requirements). Part of the expected elaborations need to
be the arguments why other identifier systems, in particular a
specific/new URI Scheme would not be suitable for the intended
purpose.
Considerations MUST include, directly or with the help of referenced Considerations MUST include, directly or with the help of referenced
stable (and preferably readily available) documents: stable (and preferably readily available) documents:
- URN assignment procedures; - URN assignment procedures;
- URN resolution/delegation; - URN resolution/delegation;
- type of resources to be identified; - 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! [[ Editorial Note: See the endnote of the next section!
In particular, the above list (from RFC 3406) seems to be rather In particular, the above list (from RFC 3406) seems to be rather
orthogonal to the primary purpose of such section (as indicated in orthogonal to the primary purpose of such section (as indicated in
the first paragraph), namely to provide evidence for the perceived the first paragraph), namely to provide evidence for the perceived
need for the new namespace. need for the new Namespace. ]]
]]
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 "Community
Considerations" section that indicates the dimensions upon which the Considerations" section that indicates the dimensions upon which the
proposer expects its community to be able to benefit by publication proposer expects its community to be able to benefit by publication
of this namespace, as well as how a general Internet user will be of this Namespace, as well as how a general Internet user will be
able to use the space if they care to do so. able to use the space if they care to do so.
Potential considerations include: Potential considerations include:
- 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: [[ Editorial Note:
It is acknowledged that, in many cases, the Namespace Considerations It is acknowledged that, in many cases, the Namespace Considerations
and Community Considerations are closely intertwined. Further, the and Community Considerations are closely intertwined. Further, the
bulleted lists above (from RFC 3406) seems to be more related to the bulleted lists above (from RFC 3406) seems to be more related to the
items in the registration template entitled "Identifier uniqueness items in the registration template entitled "Identifier uniqueness
considerations", "Identifier persistence considerations", "Process of considerations", "Identifier persistence considerations", "Process of
identifier assignment", and "Process for identifier resolution" than identifier assignment", and "Process for identifier resolution" than
to the primary objectives presented in the first paragraph above to the primary objectives presented in the first paragraph above
(also from RFC 3406). (also from RFC 3406).
In fact, namespace registration documents seen so far duplicate in In fact, Namespace registration documents seen so far duplicate in
the registration template material from the "Community the registration template material from the "Community
Considerations" that addresses the above bullets. Considerations" that addresses the above bullets.
Therefore: Should this specification now allow a combined section Therefore: Should this specification now allow a combined section
"Namespace and Community Considerations" that focuses on the "Namespace and Community Considerations" that focuses on the
(non-)utility of possible alternate namespace re-use and the (non-)utility of possible alternate namespace re-use and the
*benefits* of an independent new namespace? *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
skipping to change at page 13, line 37 skipping to change at page 14, line 49
- not be an already-registered NID; - not be an already-registered NID;
- not start with "X-" (see Section 4.1 above); - not start with "X-" (see Section 4.1 above);
- not start with "urn-" (see Section 4.2 above); - not start with "urn-" (see Section 4.2 above);
- not start with "xy-", where xy is any combination of 2 ASCII - not start with "xy-", where xy is any combination of 2 ASCII
letters (see NOTE below); letters (see NOTE below);
- not be equalt to or start with "example" (see NOTE below);
- be more than 2 characters long. - be more than 2 characters long.
NOTE: All two-letter combinations as well as two-letter combinations NOTE: All two-letter combinations as well as two-letter combinations
followed by "-" and any sequence of valid NID characters are reserved followed by "-" and any sequence of valid NID characters are reserved
for potential use as countrycode-based NIDs for eventual national for potential future use as countrycode-based NIDs for eventual
registrations of URN Namespaces. The definition and scoping of rules national registrations of URN Namespaces. The definition and scoping
for allocation of responsibility for such namespaces is beyond the of rules for allocation of responsibility for such Namespaces is
scope of this document. beyond the scope of this document.
Further, to avoid confusion, "urn" is not allowed as an NID string; Further, to avoid confusion, "urn" is not allowed as an NID string;
IANA has permanently reserved this string to prohibit assignment. 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 and the IANA experts have to ensure that the sought NID
strings are suitable and proper for the designated purpose and not
misleading, according to common sense and applicable legal rules.
The IETF Review process gives interested parties the opportunity to
rise concerns if they want to challenge proposed strings; the final
approval decision still remains with the IESG.
Registrations may be revised by updating the RFC through standard Registrations may be revised by updating the RFC through standard
IETF RFC update processes. In any case, a revised document, in the IETF RFC update processes. In any case, a revised document, in the
form of a new Internet-Draft, must be published, and the proposed form of a new Internet-Draft, must be published, and the proposed
updated template must be circulated on the urn-nid discussion list, updated template must be circulated on the urn-nid discussion list,
allowing for a two-week [[ four-week ? ]] review period before allowing for a four-week review period before pursuing RFC
pursuing RFC publication of the new document. publication of the new document.
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 always should be of relatively low security profile; however, there is
the danger of "spoofing" and providing mis-information. Information always the danger of "spoofing" and providing mis-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.
Until recently, that registry has been available in HTML, XML, and
plain text from the generic web page at
<http://www.iana.org/assignments/urn-namespaces/> [IANA-URN].
[[ NOTE: It would be preferable to restore the generic, most
universally supported (HTML) form of the registry be identified by an
implementation-neutral URL, as previously supported by IANA:
<http://www.iana.org/assignments/urn-namespaces>. Yet, currently
this URI and similar forms all resolve to an XML version.
The content there should link to alternate forms (.xml, .txt), and
those alternate versions should indicate the *other* versions; i.e.,
where the .txt version (currently only available at ftp.IANA.ORG)
also says, "This registry is also available in XML and plain text
formats.", it should better say: "This registry is also available in
HTML and XML formats." Similarly, the XML form should point to the
HTML and plain text forms. ]]
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.4.4 above describes the syntax rules for NIDs to which the Section 4.4.4 above describes the syntax rules for NIDs to which the
registry needs to obey. As pointed out in Section 4.4.4 above and in registry needs to obey.
RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn], the string "urn" is
permanently reserved and MUST NOT be assigned as an NID.
In all cases of new namespace registration proposals, the IANA should As pointed out in Section 4.4.4 above and in RFC 2141bis
[I-D.ietf-urnbis-rfc2141bis-urn], the string "urn" is permanently
reserved and MUST NOT be assigned as an NID. All strings starting
with "example" are permanently reserved for use in code and
documentation, and hence MUST NOT be assigned as an NID.
In all cases of new Namespace registration proposals, the IANA should
provisionally assign the appropriate NID (informal or formal), as provisionally assign the appropriate NID (informal or formal), as
described throughout the body of this memo, once an IESG-designated described throughout the body of this memo, once an IESG-designated
expert has confirmed that the requisite registration process steps expert has confirmed that the requisite registration process steps
have been completed. These registrations become permanent and can be have been completed. These registrations become permanent and can be
made publicly available once the registration document has been made publicly available once the registration document has been
approved by the IESG for publications as a Standards Track or approved by the IESG for publications as a Standards-Track or
Informational RFC. Informational RFC.
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, the authors of which are
cordially acknowledged. 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 and Mykyta review comments and text suggestions go to Juha Hakala, Peter Saint-
Yevstifeyev. Andre, 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-01 (work in progress), draft-ietf-urnbis-rfc2141bis-urn-02 (work in progress),
October 2011. March 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 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002. 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-URI] IANA, "URI Schemes Registry",
<http://www.iana.org/assignments/uri-schemes/>.
[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.
skipping to change at page 16, line 33 skipping to change at page 18, line 26
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.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35,
RFC 4395, February 2006.
[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.
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.
skipping to change at page 17, line 39 skipping to change at page 19, line 22
{ 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 }
Declared registrant of the namespace: Declared registrant of the Namespace:
- 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:
[[ Editorial Note: In the past, there has been iterated trouble in { Note: In the past, there has been iterated trouble in tentative
tentative registration documents with confusion between entire URN registration documents with confusion between entire URN syntax
syntax and NSS syntax (only). Since the "urn:" prefix is fixed and NSS syntax (only). Since the "urn:" prefix is fixed and the
and the NID is fully determined by the "Namespace ID" clause NID is fully determined by the "Namespace ID" clause above, in
above, in order to avoid error prone duplication, this version of order to avoid error prone duplication, this version of the
the template tentatively restricts this clause to the NSS template restricts this clause to the NSS (Namespace Specific
(namespace specific string) part of the new URNs. ]] String) part of the new URNs. }
{ {
This section should outline any structural features of identifiers This section 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 sections. 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
skipping to change at page 18, line 49 skipping to change at page 20, line 29
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:
[[ Editorial Note: This clause moved into vicinity of "syntax". ]]
{ {
This section should outline any special considerations required This section should outline any special considerations required
for conforming with the URN syntax. This is particularly for conforming with the URN syntax. This is particularly
applicable in the case of legacy naming systems that are used in applicable in the case of legacy naming systems that are used in
the context of URNs. the context 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 section should flag any such characters, and outline
necessary mappings to conform to URN syntax. Normally, this will necessary mappings to conform to URN syntax. Normally, this will
be handled by percent-encoding the symbol. be handled by percent-encoding the symbol.
} }
Rules for Lexical Equivalence of NSS part: Rules for Lexical Equivalence of NSS part:
[[ Editorial Note: This clause moved into vicinity of "syntax". ]] { Note: In the past, there has been iterated trouble in tentative
registration documents with regard to what rules can be imposed
[[ Editorial Note: In the past, there has been iterated trouble in for lexical equivalence. Since the "urn:" prefix and the NID part
tentative registration documents with regard to what rules can be both are invariably case-insensitive per RFC 3986 and RFC 2141bis,
imposed for lexical equivalence. Since the "urn:" prefix and the in order to avoid repeated confusion, this version of the template
NID part both are invariably case-insensitive per RFC 3986 and RFC tentatively restricts this clause to only the NSS part of the
2141[bis], in order to avoid repeated confusion, this version of newly specified URNs. }
the template tentatively restricts this clause to only the NSS
part of the new URN Namespace definition documents. ]]
{ {
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,
such as "character X with or without diacritic marks". such as "character X with or without diacritic marks".
Note that these are not normative statements for any kind of best Note that these are not normative statements for any kind of best
practice for handling equivalences between characters; they are practice for handling equivalences between characters; they are
statements limited to reflecting the namespace's own rules. statements limited to reflecting the namespace's own rules.
However, namespaces that seek to provide higher-level lexical
equivalence rules should preferably make use of established and
standardized normalization procedures (like the methods leading to
the various Unicode Normalization Forms, which would have to be
applied before UTF-8 encoding) and not invent their own "magic";
in practice, the utility of such things is likely to be limited
since test of lexical equivalence is a typical client-side pre-
screening operation performed by applications that try to remain
as general as possible and typically will not have built-in, NID-
specific knowledge -- ultimately, functional (or semantical)
equivalence of URNs can only be decided in the NID-specific
assignment/resolution systems, and their internal rules can be
handled much more flexibly than more complicated, nailed-down
lexical equivalence rules that are unlikely to be implemented at
large.
} }
Identifier uniqueness considerations: Identifier uniqueness considerations:
{ {
This section should address the requirement that URN identifiers This section should address the requirement that URN identifiers
be assigned uniquely -- they are assigned to at most one resource, be 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
skipping to change at page 21, line 8 skipping to change at page 23, line 8
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:
{ {
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 section
should outline is the requirements for becoming a recognized should outline is the requirements for becoming a recognized
resolver of URNs in this namespace (and being so listed in the RDS resolver of 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:
{ {
Apart from attempting resolution of a URN, a URN Namespace may Apart from attempting resolution of a URN, a URN Namespace may
provide mechanisms for "validating" a URN -- i.e., determining provide mechanisms for "validating" a URN -- i.e., determining
whether a given string is currently a validly-assigned URN. There whether a given string is currently a validly-assigned URN. There
are 2 issues here: 1) users should not "guess" URNs in a are 2 issues here: 1) users should not "guess" URNs in a
namespace; 2) when the URN Namespace is based on an existing Namespace; 2) when the URN Namespace is based on an existing
identifier system, it may not be the case that all the existing identifier system, it may not be the case that all the existing
identifiers are assigned on Day 0. The reasonable expectation is identifiers are assigned on Day 0. The reasonable expectation is
that the resource associated with each resulting URN is somehow that the resource associated with each resulting URN is somehow
related to the thing identified by the original identifier system, related to the thing identified by the original identifier system,
but those resources may not exist for each original identifier. but those resources may not exist for each original identifier.
For example, even if a telephone number-based URN Namespace was For example, even if a telephone number-based URN Namespace was
created, it is not clear that all telephone numbers would created, it is not clear that all telephone numbers would
immediately become "valid" URNs, that could be resolved using immediately become "valid" URNs, that could be resolved using
whatever mechanisms are described as part of the namespace whatever mechanisms are described as part of the Namespace
registration. registration.
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 section should outline the scope of the use of the
identifiers in this namespace. Apart from considerations of identifiers in this namespace, i.e. the precise kind of resources
to which the URNs are assigned. Apart from considerations of
private vs. public namespaces, this section is critical in private vs. public namespaces, this section is critical in
evaluating the applicability of a requested NID. For example, a evaluating the applicability of a requested NID. For example, a
namespace claiming to deal with "social security numbers" should namespace claiming to deal with "social security numbers" should
have a global scope and address all social security number have a global scope and address all social security number
structures (unlikely). On the other hand, at a national level, it structures (unlikely). On the other hand, at a national level, it
is reasonable to propose a URN Namespace for "this nation's social is reasonable to propose a URN Namespace for "this nation's social
security numbers". security numbers".
} }
Appendix B. Illustration Appendix B. Registration steps in practice
B.1. Example Template
[[ Editorial Note: Do we really need this any more?
Such an almost-concrete example likely contradicts current IESG
policy on usage of examples in RFCs. ]]
The following example is provided for the purposes of illustrating
the URN NID template described in Appendix A. Although it is based
on a hypothetical "generic Internet namespace" that has been
discussed informally within the URN WG, there are still technical and
infrastructural issues that would have to be resolved before such a
namespace could be properly and completely described.
Namespace ID:
To be assigned
Registration Information:
- version number: 1
- date: <when submitted>
Declared registrant of the namespace:
- Registering organization:
Name: Thinking Cat Example Enterprises
Postal: 1 ThinkingCat Way
Trupville, NewCountry
- Designated contact person:
Name: L. Daigle
Email: leslie@thinkingcat.example
Declaration of syntactic structure of NSS part:
The namespace specific string structure is as follows:
<FQDN>:<assigned string>
where FQDN is a fully-qualified domain name, and the assigned
string is conformant to URN syntax requirements.
Relevant ancillary documentation:
Definition of domain names, found in:
P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", STD 13,
RFC 1034, November 1987.
P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
STD 13, RFC 1035, November 1987.
Conformance with URN Syntax:
No special considerations.
Rules for Lexical Equivalence of NSS part:
FQDNs are case-insensitive. Thus, the leading portion of the URN
up to the colon after the FQDN is case-insensitive for matches.
The remainder of the identifier must be considered case-sensitive.
Identifier uniqueness considerations:
Uniqueness is guaranteed as long as the assigned string is never
reassigned for a given FQDN, and that the FQDN is never
reassigned.
N.B.: operationally, there is nothing that prevents a domain name
from being reassigned; indeed, it is not an uncommon occurrence.
This is one of the reasons that this example makes a poor URN
namespace in practice, and is therefore not seriously being
proposed as it stands.
Identifier persistence considerations:
Persistence of identifiers is dependent upon suitable delegation
of resolution at the level of "FQDN"s, and persistence of FQDN
assignment.
Same note as above.
Process of identifier assignment:
Assignment of these URNs is delegated to individual domain name
holders (for FQDNs). The holder of the FQDN registration is
required to maintain an entry (or delegate it) in the DDDS.
Within each of these delegated name partitions, the string may be
assigned per local requirements.
E.g., urn:urn-<assigned number>:thinkingcat.example:001203
Process for identifier resolution:
Domain name holders are responsible for operating or delegating
resolution servers for the FQDN in which they have assigned URNs.
Validation mechanism:
None specified.
Scope:
Global.
B.2. Registration steps in practice
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
technical review -- as an email with a pointer to the technical review -- as an email with a pointer to the
submitted I-D or inline text containing the template. submitted I-D or inline text containing the template.
skipping to change at page 25, line 13 skipping to change at page 24, line 46
necessary. necessary.
4. Once comments have been addressed (and the review period has 4. Once comments have been addressed (and the review period has
expired), send a request to IANA with the revised registration expired), send a request to IANA with the revised registration
template. template.
B) Formal NID: B) Formal NID:
1. Write an Internet-Draft describing the namespace and include 1. Write an Internet-Draft describing the namespace and include
the registration template, duly completed. Be sure to include the registration template, duly completed. Be sure to include
"Namespace Considerations", "Community Considerations", "Namespace Considerations" and "Community Considerations"
"Security Considerations", and "IANA Considerations" sections, sections (or a combined section for these), "Security
as described in Section 4.4. Considerations" and "IANA Considerations" sections, as
described in Section 4.4.
2. Submit the Internet-Draft, and send a pointer to the I-D 2. Submit the Internet-Draft, and send a pointer to the I-D
(perhaps using a copy of the I-D announcement) to (perhaps using a copy of the I-D announcement) to
urn-nid@ietf.org in order to solicit technical review. urn-nid@ietf.org in order to solicit technical review.
3. Update the Internet-Draft as necessary from comments, and 3. Update the Internet-Draft as necessary from comments, and
repeat steps 2 and 3 as needed. repeat steps 2 and 3 as needed.
4. If the Internet-Draft is the product of a working group in the 4. If the Internet-Draft is the product of a working group in the
IETF, follow the usual WG process to forward the document to IETF, follow the usual WG process to forward the document to
skipping to change at page 26, line 4 skipping to change at page 25, line 34
Appendix C. Changes from RFC 3406 Appendix C. Changes from RFC 3406
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. (after consolidation 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
Experimental namespaces and raises question of whether formal Experimental Namespaces and raises question of whether formal
"provisional" registrations would be useful; "provisional" registrations would be useful;
o Section 4: text expanded and updated; background material added; o Section 4: text expanded and updated; background material added;
added Note to challenge IANA website practices; added Note to challenge IANA website practices;
o Section 4.2 ff: changed "home" of URN-NID registration discussion o Section 4.2 ff: changed "home" of URN-NID registration discussion
list (it already had been moved to the IETF Secretariat servers); list (it already had been moved to the IETF Secretariat servers);
o Section 4.2: added Note to challenge the 2-week review period; in o Section 4.2: added Note to challenge the 2-week review period; in
current practice, that is almost always exceeded, and some regard current practice, that is almost always exceeded, and some regard
it as too short; it as too short;
o Section 4.3: largely clarified procedures as they happen in o Section 4.3: largely clarified procedures as they happen in
practice; adapted language for conformance with RFC 5226; use new practice; adapted language for conformance with RFC 5226; use new
home of URN-NID (as mentioned above); the registration template home of URN-NID (as mentioned above); the registration template
(Appendix A) now "SHOULD" be used; (Appendix A) now "SHOULD" be used;
o Section 4.3: split off new Section 4.4 on Registration Documents, o Section 4.3: split off new Section 4.4 on Registration Documents,
because registrants essentially are encouraged to follow these because registrants essentially are encouraged to follow these
guidelines for Informal namespaces as well, as far as practical; guidelines for Informal Namespaces as well, as far as practical;
replaced "RFC" by "Registration Document"; Section 4.4 is replaced "RFC" by "Registration Document"; Section 4.4 is
subdivided for all mandatory sections; subdivided for all mandatory sections;
o Section 4.4.1: made requirements a "MUST"; o Section 4.4.1: made requirements a "MUST";
o Sections 4.4.1 and 4.4.2: added common Note that challenges the o Sections 4.4.1 and 4.4.2: added common Note that challenges the
need to split Namespace and Community Considerations, based on need to split Namespace and Community Considerations, based on
observed problems in practice to separate the topics, and pointing observed problems in practice to separate the topics, and pointing
to overlap with clauses in the registration template due to to overlap with clauses in the registration template due to
bullets listed that are not so clearly related to the headlines bullets listed that are not so clearly related to the headlines
skipping to change at page 28, line 22 skipping to change at page 28, line 5
o Appendix B.2 (Registration steps in practice): updated and o Appendix B.2 (Registration steps in practice): updated and
clarified description of procedure, in alignment to current clarified description of procedure, in alignment to current
practice; practice;
o Appendix C: removed "Changes from RFC 2611"; added this change o Appendix C: removed "Changes from RFC 2611"; added this change
log; log;
o General: numerous editorial changes and enhancements, following o General: numerous editorial changes and enhancements, following
contemporary RFC style. contemporary RFC style.
Appendix D. Open Issues C.3. Changes from URNbis WG I-D -00 to -01
Usage of terminology strenghtened.
Clarified role and usage of Experimental Namespaces.
Clarified NID strings for Formal Namespaces.
Added hint that recommends Std. Track RFCs for NID applications based
on established standard namespaces, and Informational for others.
Changed standard review period from 2 to 4 weeks (pending
discussion).
Resolved with IANA: simple, traditional and generic URL used by IANA
for the URN Namespace registry. (Needed to be re-opened in -02!)
Numerous editorial enhancements and fixes.
C.4. Changes from URNbis WG I-D -01 to -02
General text edits based on evaluation of meeting and on-list
comments.
Updated and tightened the organizatorial requirements for Formal
Namespace requests.
Restored additional IANA Considerations -- due to observed defects.
Reserved NID strings "example.*" for documentation (as suggested by
Larry Masinter, Peter Saint-Andre, and Julian Reschke).
Added text on possible "higher level" methods to establish lexical
equivalence of URNs, with the caveats that such things are rather
unlikely to get traction in general-purpose client software.
Removed historical Appendix B.1 (Example Template).
Various editorial enhancements and fixes.
Updated and expanded "Issues" Appendix (below) in preparation of
usage of the IETF Issue Tracker.
Appendix D. Issues in this Draft
[ Appendix to be replaced by use of IETF Tools issue tracker. ]
For more details on the issues below, please also see the Editorial
Notes interspersed in the body of this draft.
Discuss consequences of RFC 2141bis (once consensus is achieved); if Discuss consequences of RFC 2141bis (once consensus is achieved); if
proposal for fragment part is adopted, details need to be described proposal for fragment part is adopted, details need to be described
per namespace that wants to adopt these possibilities, and maybe the per Namespace that wants to adopt these possibilities, and maybe the
registration template needs a new clause where this will be specified registration template needs a new clause where this will be specified
-- or the information has to be assigned to existing clauses. -- or the information has to be assigned to existing clauses.
More elaboration on Services. Since RFC 2483 is considered outdated, Do registration documents need more guidance and be caused to be more
but RFC 2483bis not yet a URNbis work item, we might need a registry precise in their elaboration on the applicability of Services? Since
for URN Services (initially populated from RFC 2483) that can be RFC 2483 is considered outdated, but RFC 2483bis not yet alife (nor a
referred to in namespace registration documents, thus avoiding URNbis work item), we might need a registry for URN Services
normative dependencies on a future RFC 2483bis. (initially populated from RFC 2483) that can be referred to in
Namespace registration documents, thus avoiding normative
dependencies on a future RFC 2483bis.
Do we actually need Experimental Namespaces? Do we actually need Experimental Namespaces?
[Regarded as CLOSED affirmatively at IETF 80.]
There are concerns regarding usage of "X-" NIDs, which is reported to
having proven impractical in practice. This draft version contains
tentative text to address these concerns; "X-" is now demoted to
"SHOULD" level.
The syntax of the NID strings for the various NID types is given in The syntax of the NID strings for the various NID types is given in
an informal manner (as has been done in RFC 3406); is it worth the an informal manner (as has been done in RFC 3406); is it worth the
effort to introduce ABNF for this purpose? effort to introduce ABNF for this purpose?
[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 to Increase review/timeout periods for urn-nid list and IANA experts
4 weeks? from 2 to 4 (or more) weeks? This draft version tentatively
specifies 4 weeks.
Juha Hakala has argued that the assessment of the responsible
organizations needed to assure their ability to properly operate the
Namespace could never be performed within the present 2 weeks time
span; 8 weeks might be an even better choice for the future upper
limit for the review period. It has been pointed out that even 8
weeks are miniscule with regard to the expected lifetime of the to-
be-registered Namespace and hence should not matter. In practice,
the subsequent IESG evaluation of URN Namespace registration
documents has typically needed much longer time.
Clarification of the desired content of the "Namespace Clarification of the desired content of the "Namespace
Considerations" and "Community Considerations" sections in Considerations" and "Community Considerations" sections in
registration documents. Shall we admit a combined section for both registration documents. Shall we admit a combined section for both
topics? (so far supported by 2 postings) Cf. the NOTEs in Sections topics? (so far supported by 2 postings) Cf. the NOTEs in Sections
4.4.1 and 4.4.2 for more details. 4.4.1 and 4.4.2 for more details.
[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.
Shall other strings than "urn" also be 'reserved' in the NID Appendix A: Once RFC 2483 gets updated and an IANA registry for URN
registry? (e.g. "uri", "url", "urc", "example", ...) resolution services gets established, the "Process for identifier
Do we still need Appendix B.1 ? (There are lots of real-life resolution" clause in the registration template should call out for
examples now!) enumerating the registered services that are applicable for the newly
defined URN Namespace.
How far can we go in this respect without an update to RFC 2483 at
hands?
Also see the Editorial Notes interspersed in the body of this draft. Do we really still need Appendix B.1 ? (There are lots of real-life
examples now!)
[ Old B.1 removed, old B.2 became Appendix B; ==> CLOSED ]
Author's Address Author's Address
Alfred Hoenes Alfred Hoenes
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. 113 change blocks. 
371 lines changed or deleted 438 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/