draft-ietf-urn-rfc2611bis-04.txt   rfc3406.txt 
Internet-Draft L. Daigle Network Working Group L. Daigle
URN WG Thinking Cat Enterprises Request for Comments: 3406 Thinking Cat Enterprises
Expires July 13, 2002 D. van Gulik BCP: 66 D.W. van Gulik
Category: Best Current Practice WebWeaving Obsoletes: 2611 WebWeaving
draft-ietf-urn-rfc2611bis-04.txt R. Iannella Category: Best Current Practice R. Iannella
IPR Systems IPR Systems
P. Faltstrom P. Faltstrom
Cisco Cisco
January 13, 2002 October 2002
URN Namespace Definition Mechanisms Uniform Resource Names (URN) Namespace Definition Mechanisms
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet Best Current Practices for the
all provisions of Section 10 of RFC2026. Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2002). All Rights Reserved.
http://www.ietf.org/shadow.html
Abstract Abstract
The URN WG has defined a syntax for Uniform Resource Names (URNs) This document lays out general definitions of and mechanisms for
[RFC2141], as well as some proposed mechanisms for their resolution establishing Uniform Resource Names (URN) "namespaces". The URN WG
and use in Internet applications ([RFCXXXX], [RFCYYYY]). The whole has defined a syntax for URNs in RFC 2141, as well as some proposed
rests on the concept of individual "namespaces" within the URN mechanisms for their resolution and use in Internet applications in
structure. Apart from proof-of-concept namespaces, the use of RFC 3401 and RFC 3405. The whole rests on the concept of individual
existing identifiers in URNs has been discussed ([RFC2288]), and this "namespaces" within the URN structure. Apart from proof-of-concept
document lays out general definitions of and mechanisms for namespaces, the use of existing identifiers in URNs has been
establishing URN "namespaces". discussed in RFC 2288.
This document obsoletes RFC2611.
Discussion of this document should be directed to urn-ietf@ietf.org
Table of Contents Table of Contents
Abstract ........................................................ 1 1.0 Introduction ................................................. 2
Table of Contents ............................................... 2 2.0 What is a URN Namespace? ..................................... 3
1.0 Introduction ................................................ 2 3.0 URN Namespace (Registration) Types ........................... 3
2.0 What is a URN Namespace? .................................... 3
3.0 URN Namespace (Registration) Types .......................... 4
3.1 Experimental Namespaces ..................................... 4 3.1 Experimental Namespaces ..................................... 4
3.2 Informal Namespaces ......................................... 4 3.2 Informal Namespaces ......................................... 4
3.3 Formal Namespaces ........................................... 4 3.3 Formal Namespaces ........................................... 4
4.0 URN Namespace Registration, Update, and NID Assignment 4.0 URN Namespace Registration, Update, and NID Assignment
Process ..................................................... 6 Process ..................................................... 6
4.1 Experimental ................................................ 6 4.1 Experimental ................................................ 6
4.2 Informal .................................................... 7 4.2 Informal .................................................... 6
4.3 Formal ...................................................... 7 4.3 Formal ...................................................... 7
5.0 Security Considerations ..................................... 9 5.0 Security Considerations ..................................... 9
6.0 IANA Considerations ......................................... 9 6.0 IANA Considerations ......................................... 9
7.0 References .................................................. 9 7.0 References .................................................. 9
8.0 Authors' Addresses .......................................... 10 Appendix A -- URN Namespace Definition Template ................. 11
9.0 Appendix A -- URN Namespace Definition Template ............. 11 Appendix B -- Illustration ...................................... 15
10.0 Appendix B -- Illustration ................................. 15 B.1 Example Template ............................................ 15
10.1 Example Template ........................................... 15 B.2 Registration steps in practice .............................. 17
10.2 Registration steps in practice ............................. 17 Appendix C -- Changes from RFC 2611 ............................. 18
11.0 Appendix C -- Changes from RFC2611 ......................... 18 C.1 Detailed Document Changes ................................... 19
11.1 Detailed Document Changes .................................. 19 Authors' Addresses .............................................. 21
Full Copyright Statement ........................................ 22
1.0 Introduction 1.0 Introduction
Uniform Resource Names (URNs) are resource identifiers with the Uniform Resource Names (URNs) are resource identifiers with the
specific requirements for enabling location independent specific requirements for 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
[RFC3305] with the specific goal of providing persistent naming of
resources.
There are 2 assumptions that are key to this document: There are 2 assumptions that are key to this document:
Assumption #1: Assumption #1:
Assignment of a URN is a managed process. 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: Assumption #2:
The space of URN namespaces is managed. 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 syntax definition) are valid URN namespaces. A URN namespace must
must have a recognized definition in order to be valid. have a recognized definition in order to be valid.
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, along with the mechanism template for explicit namespace definition, as well as provide the
for associating an identifier (called a "Namespace ID", or NID) which mechanism for associating an identifier (called a "Namespace ID", or
is registered with the Internet Assigned Numbers Authority, IANA. NID) which is registered with the Internet Assigned Numbers Authority
(IANA).
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 "resolution" of any processes for the creation of URN namespaces. If "resolution" of any
so-created URN identifiers is desired, a separate process of so-created URN identifiers is desired, a separate process of
registration in a global NID directory, such as that provided by the registration in a global NID directory, such as that provided by the
DDDS system [RFCXXXX], is necessary. See [RFCYYYY] for information DDDS system [RFC3401], is necessary. See [RFC3405] for information
on obtaining registration in the DDDS global NID directory. on obtaining registration in the DDDS global NID directory.
2.0 What is a URN Namespace? 2.0 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 1 resource, nor are they ever re-assigned to a different
resource. A single resource, however, may have more than one URN resource. A single resource, however, may have more than one URN
assigned to it for different purposes. A URN namespace itself has an assigned to it for different purposes. A URN namespace itself has an
identifier in order to identifier in order to:
- ensure global uniqueness of URNs - ensure global uniqueness of URNs
- (where desired) provide a cue for the structure of the - (where desired) provide a cue for the structure of the
identifier identifier
For example, many identifier systems make use strings of numbers as For example, many identifier systems may use strings of numbers as
identifiers (e.g., ISBN, ISSN, phone numbers). It is conceivable that identifiers (e.g., ISBN, ISSN, phone numbers). It is conceivable
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 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
skipping to change at page 4, line 8 skipping to change at page 3, line 46
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.0 URN Namespace (Registration) Types 3.0 URN Namespace (Registration) Types
There are 3 categories of URN namespaces defined here, distinguished There are three categories of URN namespaces defined here,
by expected level of service and required procedures for distinguished by expected level of service and required procedures
registration. Registration processes for each of these namespace for registration. Registration processes for each of these namespace
types are given in Section 4.0. types are given in Section 4.0.
3.1 Experimental Namespaces 3.1 Experimental Namespaces
These are not explicitly registered with IANA. They take the form These are not explicitly registered with IANA. They take the form:
X-<NID> X-<NID>
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. contexts.
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
skipping to change at page 4, line 42 skipping to change at page 4, line 34
alphanumeric NID to registered informal namespaces, per the process alphanumeric NID to registered informal namespaces, per the process
outlined in Section 4.0. outlined in Section 4.0.
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, a communities or networks not connected to the Internet. For example,
NID is requested that is meant for naming of physics research. If a NID that is meant for naming of physics research is requested. If
that NID request required that the user use a propietary network or that NID request required that the user use a proprietary network or
service that was not at all open to the general Internet user then it service that was not at all open to the general Internet user, then
would make a poor request for a formal NID. The intent is that, while it would make a poor request for a formal NID. The intent is that,
the community of those who may actively use the names assigned within while the community of those who may actively use the names assigned
that NID may be small (but no less important), the potential use of within that NID may be small (but no less important), the potential
names within that NID is open to any user on the Internet. use of names within that NID is open to any user on the Internet.
It is expected that Formal NIDs may be applied to namespaces where It is expected that Formal NIDs may be applied to namespaces where
some aspects are not fully open. For example, a namespace may make some aspects are not fully open. For example, a namespace may make
use of a fee-based, privately managed, or proprietary registry for use of a fee-based, privately managed, or proprietary registry for
assignment of URNs in the namespace, but it may still provide benefit assignment of URNs in the namespace, but it may still provide benefit
to some Internet users if the services associated have openly- to some Internet users if the services associated have openly-
published access protocols. 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 the community benefit of formally establishing the new namespace and of the community benefit from formally establishing
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, some consideration as to the longevity and
maintainability of the namespace must be given. The URN WG discussed maintainability of the namespace must be given. The URN WG discussed
at length the issue of finding objective measures for predicting (a at length the issue of finding objective measures for predicting (a
priori) the continued success of a namespace. No conclusion was priori) the continued success of a namespace. No conclusion was
reached -- much depends on factors that are completely beyond the reached -- much depends on factors that are completely beyond the
technical scope of the namespace. However, the collective experience technical scope of the namespace. However, the collective experience
of the IETF community does contain a wealth of information on of the IETF community does contain a wealth of information on
technical factors that will prevent longevity of identification. The technical factors that will prevent longevity of identification. The
IESG may elect not to publish a proposed namespace RFC if the IETF IESG may elect not to publish a proposed namespace RFC if the IETF
community consensus is that it contains technical flaws that will community consensus is that it contains technical flaws that will
prevent (or seriously impair the possibility of) persistent prevent (or seriously impair the possibility of) persistent
identification. identification.
The kinds of things the URN WG discussed included: The kinds of things the URN WG discussed included:
- the organization maintaining the URN namespace should
demonstrate stability and ability to maintain the URN namespace
for a long time, and/or it should be clear how the namespace can
continue to be usable/useful if the organization ceases to be
able to foster it;
- it should demonstrate ability and competency at name assignment - the organization maintaining the URN namespace should
in order to facilitate persistence (e.g. to minimize the demonstrate stability and the ability to maintain the URN
likelihood of conflicts); namespace for a long time, and/or it should be clear how the
namespace can continue to be usable/useful if the organization
ceases to be able to foster it;
- it should commit to not re-assigning existing names and allowing - it should demonstrate ability and competency in name assignment.
old names to continue to be valid, even if the owners or This should improve the likelihood of persistence (e.g. to
assignees of those names are no longer members or customers of minimize the likelihood of conflicts);
that organization. This does not mean that there must be
resolution of such names, but it does mean that they must not - it should commit to not re-assigning existing names and
resolve the name to false or stale information, and it means allowing old names to continue to be valid, even if the owners
that they must not be reassigned. or assignees of those names are no longer members or customers
of that organization. This does not mean that there must be
resolution of such names, but that they must not resolve the
name to false or stale information, and that they must not be
reassigned.
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 namespace. the technical merits of any proposed Formal namespace.
4.0 URN Namespace Registration, Update, and NID Assignment Process 4.0 URN Namespace Registration, Update, and NID Assignment Process
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 or may request a disclosure, a URN namespace may be assigned or may request a
particular identifier. The "IANA Considerations" document [RFC2434] particular identifier. The "IANA Considerations" document [RFC2434]
suggests the need to specify update mechanisms for registrations -- suggests the need to specify update mechanisms for registrations --
who is given the authority to do so, from time to time, and what are who is given the authority to do so, from time to time, and what are
the processes. Since URNs are meant to be persistently useful, few the processes. Since URNs are meant to be persistently useful, few
(if any) changes should be made to the structural interpretation of (if any) changes should be made to the structural interpretation of
URN strings (e.g., adding or removing rules for lexical equivalence URN strings (e.g., adding or removing rules for lexical equivalence
that might affect the interpretation of URN IDs already assigned). that might affect the interpretation of URN IDs already assigned).
However, it may be important to introduce clarifications, expand the However, it may be important to introduce clarifications, expand the
list of authorized URN assigners, etc, over the natural course of a list of authorized URN assigners, etc, over the natural course of a
namespace's lifetime. Specific processes are outlined below. namespace's lifetime. Specific processes are outlined below.
The official list of registered URN namespaces is maintained by IANA. The official list of registered URN namespaces is maintained by IANA.
URN namespace registrations are currently being posted in the URN namespace registrations are currently being posted in the
anonymous FTP directory anonymous FTP directory:
ftp://ftp.isi.edu/in-notes/iana/assignments/URN-namespaces/ http://www.iana.org/assignments/urn-namespaces
See [STD2] for the current location of IANA registry. See [RFC3232] for the current location of IANA registry.
The registration and maintenance procedures vary slightly from one The registration and maintenance procedures vary slightly from one
namespace type (as defined in Section 3.0) to another. namespace type (as defined in Section 3.0) to another.
4.1 Experimental 4.1 Experimental
These are not explicitly registered with IANA. They take the form These are not explicitly registered with IANA. They take the form:
X-<NID> X-<NID>
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. contexts.
As there is no registration, no registration maintenance procedures As there is no registration, no registration maintenance procedures
are needed. are needed.
4.2 Informal 4.2 Informal
These are registered with IANA and are assigned a number sequence as These are registered with IANA and are assigned a number sequence as
an identifier, in the format: an identifier, in the format:
"urn-" <number> "urn-" <number>
where <number> is chosen by the IANA on a First Come First Served where <number> is chosen by the IANA on a First Come First Served
basis (see [RFC2434]). basis (see [RFC2434]).
Registrants should send a copy of the registration template (see Registrants should send a copy of the registration template (see
Appendix A), duly completed, to the Appendix A), duly completed, to:
urn-nid@apps.ietf.org urn-nid@apps.ietf.org
mailing and allow for a 2 week discussion period for clarifying the and allow for a 2 week discussion period for clarifying the
expression of the registration information and suggestions for expression of the registration information and suggestions for
technical improvements to the namespace proposal. technical improvements to the namespace proposal.
After suggestions for clarification of the registration information After suggestions for clarification of the registration information
have been incorporated, the template may be submitted to: have been incorporated, the template may be submitted for assignment
of a NID to:
iana@iana.org
for assignment of a NID. iana@iana.org
The only restrictions on <number> are that it consist strictly of The only restrictions on <number> are that it consist strictly of
digits and that it not cause the NID to exceed length limitations digits and that it not cause the NID to exceed length limitations
outlined in the URN syntax ([RFC2141]). outlined in the URN syntax ([RFC2141]).
Registrations may be updated by the original registrant, or an entity Registrations may be updated by the original registrant, or an entity
designated by the registrant, by updating the registration template, designated by the registrant, by updating the registration template,
submitting it to the discussion list for a further 2 week discussion submitting it to the discussion list for a further 2 week discussion
period, and finally resubmitting it to IANA, as described above. period, and finally resubmitting it to IANA, as described above.
4.3 Formal 4.3 Formal
Formal NIDs are assigned via IETF Consensus, as defined in [RFC2434]: Formal NIDs are assigned via IETF Consensus, as defined in [RFC2434]:
"IETF Consensus - New values are assigned through the IETF "IETF Consensus - New values are assigned through the IETF
consensus process. Specifically, new assignments are made via consensus process. Specifically, new assignments are made via
RFCs approved by the IESG. Typically, the IESG will seek RFCs approved by the IESG. Typically, the IESG will seek input on
input on prospective assignments from appropriate persons prospective assignments from appropriate persons (e.g., a relevant
(e.g., a relevant Working Group if one exists)." Working Group if one exists)."
Thus, the Formal NID application is made via publication of an RFC Thus, the Formal NID application is made via publication of an RFC
through standard IETF processes. The RFC need not be standards- through standard IETF processes. The RFC need not be standards-
track, but it will be subject to IESG review and acceptance pursuant track, but it will be subject to IESG review and acceptance pursuant
to the guidelines written here (as well as standard RFC publication to the guidelines written here (as well as standard RFC publication
guidelines). The template defined in Appendix A may be included as guidelines). The template defined in Appendix A may be included as
part of an RFC defining some other aspect of the namespace, or it may part of an RFC defining some other aspect of the namespace, or it may
be put forward as an RFC in its own right. The proposed template be put forward as an RFC in its own right. The proposed template
should be sent to the should be sent to the:
urn-nid@apps.ietf.org urn-nid@apps.ietf.org
mailing list to allow for a 2 week discussion period for clarifying mailing list to allow for a two week discussion period for clarifying
the expression of the registration information, before the IESG the expression of the registration information, before the IESG
reviews the document. reviews the document.
The RFC must include a "Namespace Considerations" section, which The RFC must include a "Namespace Considerations" section, which
outlines the perceived need for a new namespace (i.e., where existing outlines the perceived need for a new namespace (i.e., where existing
namespaces fall short of the proposer's requirements). namespaces fall short of the proposer's requirements).
Considerations might include: Considerations might include:
- 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.
The RFC must also include a "Community Considerations" section, which The RFC must also include a "Community Considerations" section, which
indicates the dimensions upon which the proposer expects its indicates the dimensions upon which the proposer expects its
community to be able to benefit by publication of this namespace as community to be able to benefit by publication of this namespace as
well as how a general Internet user will be able to use the space if well as how a general Internet user will be able to use the space if
they care to do so. Potential considerations include: they care to do so. 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 services for the namespace (client)
access services for the namespace (client)
The RFC must include an "IANA Considerations" section, indicating The RFC must include an "IANA Considerations" section, indicating
that the document includes a URN NID registration that is to be that the document includes a URN NID registration that is to be
entered into the IANA registry of URN NIDs. entered into the IANA registry of URN NIDs.
A particular NID string is requested, and is assigned by IETF A particular NID string is requested, and is assigned by IETF
consensus (as defined in [RFC2434]), with the additional constraints consensus (as defined in [RFC2434]), with the additional constraints
that the NID string must that the NID string must:
- not be an already-registered NID
- not start with "x-" (see Type I above) - not be an already-registered NID
- not start with "urn-" (see Type II above) - not start with "x-" (see Type I above)
- not start with "XY-", where XY is any combination of 2 - not start with "urn-" (see Type II above)
ASCII letters (see NOTE, below) - not start with "XY-", where XY is any combination of 2 ASCII
- be more than 2 letters long letters (see NOTE, below)
- be more than 2 letters long
NOTE: ALL two-letter combinations, and two-letter combinations NOTE: ALL two-letter combinations, and two-letter combinations
followed by "-" and any sequence of valid NID characters, are followed by "-" and any sequence of valid NID characters are reserved
reserved for potential use as countrycode- based NIDs for eventual for potential use as countrycode-based NIDs for eventual national
national registrations of URN namespaces. The definition and registrations of URN namespaces. The definition and scoping of rules
scoping of rules for allocation of responsibility for such namespaces for allocation of responsibility for such namespaces is beyond the
is beyond the scope of this document. scope of this document.
Registrations may be revised by updating the RFC through standard Registrations may be revised by updating the RFC through standard
IETF RFC update processes (see [RFC2606] for a discussion of IETF IETF RFC update processes (see [RFC2606] for a discussion of IETF
process). In any case, a revised document, in the form of a new process). In any case, a revised document, in the form of a new
Internet-Draft, must be published, and the proposed updated template Internet-Draft, must be published, and the proposed updated template
must be circulated on the urn-nid discussion list, allowing for a 2 must be circulated on the urn-nid discussion list, allowing for a 2
week review period before pursuing publication of the new RFC week review period before pursuing publication of the new RFC
document. document.
5.0 Security Considerations 5.0 Security Considerations
skipping to change at page 9, line 46 skipping to change at page 9, line 40
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. In all cases, the IANA should assign the appropriate NID maintained. In all cases, the IANA should assign the appropriate NID
(informal or formal), as described above, once an IESG-designated (informal or formal), as described above, 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. This document defines processes to replace have been completed. This document defines processes to replace
those outlined in [RFC2611]. those outlined in [RFC2611].
7.0 References 7.0 References
[ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange [ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange formats
formats - Information interchange - Representation of - Information interchange - Representation of dates and
dates and times" times"
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3",
RFC 2026, October 1996.
[RFC2611] Daigle, L., D. van Gulik, R. Iannella, P. Faltstrom,
"URN Namespace Definition Mechanisms", RFC 2611,
June 1999.
[RFC2288] Lynch, C., Preston, C. and R. Daniel, "Using Existing
Bibliographic Identifiers as Uniform Resource Names", RFC
2288, February 1998.
[RFCXXXX] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS Standard", RFC XXXX.
[RFCYYYY] Mealling, M., "Assignment Procedures for URI Resolution
Using DNS", RFCYYYY.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[STD2] Reynolds, J, and J. Postel, "Assigned Numbers", STD 2,
October 1994.
[RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, December 1994. Uniform Resource Names", RFC 1737, December 1994.
[RFC2276] Sollins, K., "Architectural Principles of Uniform [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
Resource Name Resolution", RFC 2276, January 1998. 3", BCP 9, RFC 2026, October 1996.
8.0 Authors' Addresses [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
Leslie L. Daigle [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource
Thinking Cat Enterprises Name Resolution", RFC 2276, January 1998.
EMail: leslie@thinkingcat.com [RFC2288] Lynch, C., Preston, C. and R. Daniel, "Using Existing
Bibliographic Identifiers as Uniform Resource Names", RFC
2288, February 1998.
Dirk-Willem van Gulik [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
WebWeaving IANA Considerations Section in RFCs", BCP 26, RFC 2434,
Plein 1813 - 5a October 1998.
8545 HX Arnhem
The Netherlands
Phone: +39 0332 78 0014 (Phone and Fax) [RFC2611] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom,
EMail: Dirkx@webweaving.org "URN Namespace Definition Mechanisms", RFC 2611, June 1999.
Renato Iannella [RFC3232] Reynolds, J, Editor, "Assigned Numbers: RFC 1700 is
IPR Systems Pty Ltd. Replaced by an On-line Database", RFC 3232, January 2002.
EMail: renato@iprsystems.com [RFC3305] Mealling, M. (Ed.) and R. Denenberg (Ed.), "Report from the
Joint W3C/IETF URI Planning Interest Group: Uniform
Resource Identifiers (URIs), URLs, and Uniform Resource
Names (URNs): Clarifications and Recommendations", RFC
3305, August 2002.
Patrik Faltstrom [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Cisco Systems Inc Part One: The Comprehensive DDDS", RFC 3401, October 2002.
170 W Tasman Drive SJ-13/2
San Jose CA 95134
USA
EMail: paf@cisco.com [RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
URL: http://www.cisco.com Part Five: URI.ARPA Assignment Procedures", RFC 3405,
October 2002.
9.0 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. Apart from providing a mechanism for following information template. Apart from providing a mechanism for
disclosing structure of the URN namespace, this information is disclosing structure of the URN namespace, this information is
designed to be useful for 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) applicable)
- 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" and "IANA Considerations", "Community Considerations" and "IANA
Considerations", as described in Section 4.3. Considerations", as described in Section 4.3.
Information in the template is as follows: Information in the template is as follows:
Namespace ID: Namespace ID:
Assigned by IANA. In the case of a Formal NID registration,
a particular NID string may be requested. Assigned by IANA. In the case of a Formal NID registration, a
particular NID string may be requested.
Registration Information: Registration Information:
This is information to identify the particular version of This is information to identify the particular version of
registration information: registration information:
- registration version number: starting with 1, incrementing by 1 - registration version number: starting with 1, incrementing by 1
with each new version with each new version
- registration date: date submitted to the IANA, using the format - registration date: date submitted to the IANA, using the format
YYYY-MM-DD outlined in [ISO8601]:
as outlined in [ISO8601]. YYYY-MM-DD
Declared registrant of the namespace: Declared registrant of the namespace:
This includes: This includes:
Registering organization Registering organization
Name Name
Address Address
Designated contact person Designated contact person
Name Name
Coordinates (at least one of: e-mail, phone, postal address) Coordinates (at least one of: e-mail, phone, postal address)
skipping to change at page 12, line 39 skipping to change at page 12, line 18
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 structure may also be used for determining realistic
caching/shortcuts approaches; suitable caveats should be provided. caching/shortcuts approaches; suitable caveats should be provided.
If there are any specific character encoding rules (e.g., which If 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) - a regular expression - the structure is opaque (no exposition)
for parsing the identifier into components, including naming - a regular expression for parsing the identifier into
authorities components, including naming authorities
Relevant ancillary documentation: Relevant ancillary documentation:
This section should list any RFCs, standards, or other published This section should list any RFCs, standards, or other published
documentation that defines or explains all or part of the documentation that defines or explains all or part of the
namespace structure. namespace structure.
Answers might include, but are not limited to: Answers might include, but are not limited to:
- RFCs outlining syntax of the namespace - RFCs outlining syntax of the namespace
- Other of the defining community's (e.g., ISO) documents - Other of the defining community's (e.g., ISO) documents
outlining syntax of the identifiers in the namespace outlining syntax of the identifiers in the namespace
- Explanatory material introducing the namespace - Explanatory material introducing the namespace
Identifier uniqueness considerations: Identifier uniqueness considerations:
This section should address the requirement that URN identifiers be This section should address the requirement that URN identifiers
assigned uniquely -- they are assigned to at most one resource, and be assigned uniquely -- they are assigned to at most one resource,
are not reassigned. and are not reassigned.
(Note that the definition of "resource" is fairly broad; for example, (Note that the definition of "resource" is fairly broad; for
information on "Today's Weather" might be considered a single example, information on "Today's Weather" might be considered a
resource, although the content is dynamic.) single resource, although the content is dynamic.)
Possible answers include, but are not limited to: Possible answers include, but are not limited to:
- exposition of the structure of the identifiers, and partitioning - exposition of the structure of the identifiers, and
of the space of identifiers amongst assignment authorities which partitioning of the space of identifiers amongst assignment
are individually responsible for respecting uniqueness rules authorities which are individually responsible for respecting
- identifiers are assigned sequentially uniqueness rules
- information is withheld; the namespace is opaque - identifiers are assigned sequentially
- information is withheld; the namespace is opaque
Identifier persistence considerations: Identifier persistence considerations:
Although non-reassignment of URN identifiers ensures that a URN Although non-reassignment of URN identifiers ensures that a URN
will persist in identifying a particular resource even after the will persist in identifying a particular resource even after the
"lifetime of the resource", some consideration should be given to "lifetime of the resource", some consideration should be given to
the persistence of the usability of the URN. This is particularly the persistence of the usability of the URN. This is particularly
important in the case of URN namespaces providing global important in the case of URN namespaces providing global
resolution. resolution.
Possible answers include, but are not limited to: Possible answers include, but are not limited to:
- quality of service considerations - quality of service considerations
Process of identifier assignment: Process of identifier assignment:
This section should detail the mechanisms and/or authorities for This section should detail the mechanisms and/or authorities for
assigning URNs to resources. It should make clear whether assigning URNs to resources. It should make clear whether
assignment is completely open, or if limited, how to become an assignment is completely open, or if limited, how to become an
assigner of identifiers, and/or get one assigned by existing assigner of identifiers, and/or get one assigned by existing
assignment authorities. Answers could include, but are not assignment authorities.
limited to:
- assignment is completely open, following a particular algorithm Answers could include, but are not limited to:
- assignment is delegated to authorities recognized by a
particular organization (e.g., the Digital Object Identifier - assignment is completely open, following a particular algorithm
Foundation controls the DOI assignment space and its delegation) - assignment is delegated to authorities recognized by a
- assignment is completely closed (e.g., for a private particular organization (e.g., the Digital Object Identifier
organization) Foundation controls the DOI assignment space and its
delegation)
- assignment is completely closed (e.g., for a private
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 registerd in an RDS (Resolution Discovery System, see it must be registered in an RDS (Resolution Discovery System, see
[RFC2276]) such as DDDS. Resolution then proceeds according to [RFC2276]) such as DDDS. Resolution then proceeds according to
standard URI resolution processes, and the mechanisms of the RDS. standard URI resolution processes, and the mechanisms of the RDS.
What this section should outline is the requirements for becoming What this section should outline is the requirements for becoming
a recognized resolver of URNs in this namespace (and being so- a recognized resolver of URNs in this namespace (and being so-
listed in the RDS registry). listed in the RDS 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
Rules for Lexical Equivalence: Rules for Lexical Equivalence:
If there are particular algorithms for determining equivalence If there are particular algorithms for determining equivalence
between two identifiers in the underlying namespace (hence, in the between two identifiers in the underlying namespace (hence, in the
URN string itself), rules can be provided here. 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, such - Namespace-defined equivalences between specific characters,
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.
Conformance with URN Syntax: Conformance with URN 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
skipping to change at page 15, line 13 skipping to change at page 14, line 41
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 hex encoding the symbol. be handled by hex encoding the symbol.
For example, see the section on SICIs in [RFC2288]. For example, see the section on SICIs in [RFC2288].
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 mechanism for "validating" a URN -- i.e., determining whether provide mechanisms for "validating" a URN -- i.e., determining
a given string is currently a validly-assigned URN. There are 2 whether a given string is currently a validly-assigned URN. There
issues here: 1) users should not "guess" URNs in a namespace; 2) when are 2 issues here: 1) users should not "guess" URNs in a
the URN namespace is based on an existing identifier system, it may namespace; 2) when the URN namespace is based on an existing
not be the case that all the existing identifiers are assigned on Day identifier system, it may not be the case that all the existing
0. The reasonable expectation is that the resource associated with identifiers are assigned on Day 0. The reasonable expectation is
each resulting URN is somehow related to the thing identified by the that the resource associated with each resulting URN is somehow
original identifier system, but those resources may not exist for related to the thing identified by the original identifier system,
each original identifier. For example, even if a telephone number- but those resources may not exist for each original identifier.
based URN namespace was created, it is not clear that all telephone For example, even if a telephone number-based URN namespace was
numbers would immediately become "valid" URNs, that could be resolved created, it is not clear that all telephone numbers would
using whatever mechanisms are described as part of the namespace immediately become "valid" URNs, that could be resolved using
registration. whatever mechanisms are described as part of the namespace
registration.
A validation mechanims 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. 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 in "social security numbers" should namespace claiming to deal in "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".
10.0 Appendix B -- Illustration Appendix B -- Illustration
10.1 Example Template B.1 Example Template
The following example is provided for the purposes of illustration of The following example is provided for the purposes of illustrating
the URN NID template described in Appendix A. Although it is based the URN NID template described in Appendix A. Although it is based
on a hypothetical "generic Internet namespace" that has been on a hypothetical "generic Internet namespace" that has been
discussed informally within the URN WG, there are still technical and discussed informally within the URN WG, there are still technical and
infrastructural issues that would have to be resolved before such a infrastructural issues that would have to be resolved before such a
namespace could be properly and completely described. namespace could be properly and completely described.
Namespace ID: Namespace ID:
To be assigned To be assigned
Registration Information: Registration Information:
Version 1 Version 1
Date: <when submitted> Date: <when submitted>
Declared registrant of the namespace: Declared registrant of the namespace:
Name: Thinking Cat Enterprises Name: Thinking Cat Enterprises
skipping to change at page 16, line 38 skipping to change at page 16, line 27
URN:<assigned number>:<FQDN>:<assigned string> URN:<assigned number>:<FQDN>:<assigned string>
where FQDN is a fully-qualified domain name, and the assigned where FQDN is a fully-qualified domain name, and the assigned
string is conformant to URN syntax requirements. string is conformant to URN syntax requirements.
Relevant ancillary documentation: Relevant ancillary documentation:
Definition of domain names, found in: Definition of domain names, found in:
P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
RFC1035, November 1987. RFC 1035, November 1987.
Identifier uniqueness considerations: Identifier uniqueness considerations:
Uniqueness is guaranteed as long as the assigned string is never Uniqueness is guaranteed as long as the assigned string is never
reassigned for a given FQDN, and that the FQDN is never reassigned for a given FQDN, and that the FQDN is never
reassigned. reassigned.
N.B.: operationally, there is nothing that prevents a domain name N.B.: operationally, there is nothing that prevents a domain name
from being reassigned; indeed, it is not an uncommon occurrence. from being reassigned; indeed, it is not an uncommon occurrence.
This is one of the reasons that this example makes a poor URN This is one of the reasons that this example makes a poor URN
skipping to change at page 17, line 15 skipping to change at page 17, line 7
Identifier persistence considerations: Identifier persistence considerations:
Persistence of identifiers is dependent upon suitable delegation Persistence of identifiers is dependent upon suitable delegation
of resolution at the level of "FQDN"s, and persistence of FQDN of resolution at the level of "FQDN"s, and persistence of FQDN
assignment. assignment.
Same note as above. Same note as above.
Process of identifier assignment: Process of identifier assignment:
Assignment of these URNs delegated to individual domain name Assignment of these URNs is delegated to individual domain name
holders (for FQDNs). The holder of the FQDN registration is holders (for FQDNs). The holder of the FQDN registration is
required to maintain an entry (or delegate it) in the DDDS. required to maintain an entry (or delegate it) in the DDDS.
Within each of these delegated name partitions, the string may be Within each of these delegated name partitions, the string may be
assigned per local requirements. assigned per local requirements.
e.g. urn:<assigned number>:thinkingcat.com:001203 e.g., urn:<assigned number>:thinkingcat.com:001203
Process for identifier resolution: Process for identifier resolution:
Domain name holders are responsible for operating or delegating Domain name holders are responsible for operating or delegating
resolution servers for the FQDN in which they have assigned URNs. resolution servers for the FQDN in which they have assigned URNs.
Rules for Lexical Equivalence: Rules for Lexical Equivalence:
FQDNs are case-insensitive. Thus, the portion of the URN FQDNs are case-insensitive. Thus, the portion of the URN
urn:<assigned number>:<FQDN>: urn:<assigned number>:<FQDN>:
is case-insenstive for matches. The remainder of the identifier is case-insensitive for matches. The remainder of the identifier
must be considered case-sensitve. must be considered case-sensitive.
Conformance with URN Syntax: Conformance with URN Syntax:
No special considerations. No special considerations.
Validation mechanism: Validation mechanism:
None specified. None specified.
Scope: Scope:
Global. Global.
10.2 Registration steps in practice 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:
Informal NID: 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@apps.ietf.org 2. Communicate the registration template to urn-nid@apps.ietf.org
for technical review -- as a published I-D, or text e-mail message for technical review -- as a published I-D, or text e-mail
containing the template. message containing the template.
3. Update the registration template as necessary from comments, and 3. Update the registration template as necessary from comments,
repeat steps 2 and 3 as necessary. and repeat steps 2 and 3 as necessary.
4. Once comments have been addressed (and the review period has 4. Once comments have been addressed (and the review period has
expired) end a request to IANA with the revised registration expired), send a request to IANA with the revised registration
template. template.
Formal NID: Formal NID:
1. Write an Internet-Draft describing the namespace and including 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" and "IANA "Namespace Considerations", "Community Considerations" and
Considerations" sections, as described in Section 4.3. "IANA Considerations" sections, as described in Section 4.3.
2. Send the Internet-Draft to the I-D editor, and send a copy to 2. Send the Internet-Draft to the I-D editor, and send a copy to
urn-nid@apps.ietf.org for technical review. urn-nid@apps.ietf.org for technical review.
3. Update the Internet-Draft as necessary from comments, and repeat 3. Update the Internet-Draft as necessary from comments, and
steps 2 and 3 as needed. repeat steps 2 and 3 as needed.
4. Send a request to the IESG to publish the I-D as an RFC. The 4. Send a request to the IESG to publish the I-D as an RFC. The
IESG may request further changes (published as I-D revisions) IESG may request further changes (published as I-D revisions)
and/or direct discussion to designated working groups, area and/or direct discussion to designated working groups, area
experts, etc. experts, etc.
5. If the IESG approves the document for publication as an RFC, 5. If the IESG approves the document for publication as an RFC,
send a request to IANA to register the requested NID. send a request to IANA to register the requested NID.
11.0 Appendix C -- Changes from RFC2611 Appendix C -- Changes from RFC 2611
This revision of [RFC2611] adds more detail describing the process of This revision of [RFC2611] adds more detail describing the process of
registering a URN namespace identifier (in terms of mechanical registering a URN namespace identifier (in terms of mechanical
steps). steps).
This version of the document also separates the process (mechanics) This version of the document also separates the process (mechanics)
from the discussion of the requirements for namespaces, attempting to from the discussion of the requirements for namespaces, attempting to
make the latter as objective as possible. make the latter as objective as possible.
Throughout the document, references have been updated to the current Throughout the document, references have been updated to the current
versions of the DDDS and related documentation (which collectively versions of the DDDS and related documentation (which collectively
obsolete [RFC2168] and related drafts). obsolete [RFC2168] and related drafts).
11.1 Detailed Document Changes C.1 Detailed Document Changes
Added table of contents Added table of contents
Section 2 Section 2
Clarified the definition of a URN namespace, uniqueness of Clarified the definition of a URN namespace, the uniqueness of
assignment, and that a single resource may have more than one assignment, and that a single resource may have more than one
identifier associated with it. identifier associated with it.
Clarified the "number example" -- that the same string may appear in Clarified the "number example" -- that the same string may appear in
2 different namespaces, and be applied to different resources. 2 different namespaces, and be applied to different resources.
Originally used ISBN/ISSN example, but structurally this is not Originally used ISBN/ISSN example, but structurally this is not
possible. possible.
Section 3 (new) Section 3 (new)
This section explicitly defines the 3 categories of namespace -- This section explicitly defines the 3 categories of namespace --
Experimental, Informal and Formal. This section provides a Experimental, Informal and Formal. This section provides a
description of the intended use of the different namespace types, as description of the intended use of the different namespace types, as
well as some acceptability guidelines for Formal namespaces (which well as some acceptability guidelines for Formal namespaces (which
require IETF review). require IETF review).
Section 4.0 Section 4.0
Spelled out the name of RFC2434 ("IANA Considerations"). Spelled out the name of RFC 2434 ("IANA Considerations").
Provided a pointer to the IANA URN namespace registry. Provided a pointer to the IANA URN namespace registry.
Sections 4.1-4.3 new subsection divisions of the existing discussion Sections 4.1-4.3
of individual namespace types.
New subsection divisions of the existing discussion of individual
namespace types.
Section 4.2 Section 4.2
Corrected reference to URN Syntax document (RFC2141, not RFC2168). Corrected reference to URN Syntax document (RFC 2141, not RFC 2168).
Section 4.3 Section 4.3
Added clarifying text as to the intended nature of Formal namespaces Added clarifying text as to the intended nature of Formal namespaces
and processes for registering them. and processes for registering them.
Added text to describe the requirement for a "Namespace Added text to describe the requirement for a "Namespace
Considerations" section in RFCs defining Formal namespaces. Defined Considerations" section in RFCs defining Formal namespaces. Defined
the required content of that section. the required content of that section.
skipping to change at page 20, line 32 skipping to change at page 20, line 23
Added text to further clarify the (IETF) process for revising Formal Added text to further clarify the (IETF) process for revising Formal
namespace registrations through the RFC and IETF review process. namespace registrations through the RFC and IETF review process.
Section 6 Section 6
New section -- added text to describe the IANA considerations for New section -- added text to describe the IANA considerations for
this document. this document.
Section 7 -- References Section 7 -- References
Added references to revised NAPTR documentation ([RFCXXXX]), and the Added references to revised NAPTR documentation ([RFC3401]), and the
previous version of this document ([RFC2611]). previous version of this document ([RFC2611]).
Section 9 -- Appendix A Appendix A
section created by moving the "URN Namespace Definition Template" Section created by moving the "URN Namespace Definition Template"
(RFC2611's Section 3) to an appendix. (RFC2611's Section 3) to an appendix.
Added references to the new requirements for "Namespace Added references to the new requirements for "Namespace
Considerations", "Community Considerations", and "IANA Considerations", "Community Considerations", and "IANA
Considerations" sections for Formal namespace registrations. Considerations" sections for Formal namespace registrations.
Clarified the "Declared registrant of the namespace" template Clarified the "Declared registrant of the namespace" template
element. element.
Added text to describe the purpose and scope of the "Validating Added text to describe the purpose and scope of the "Validating
Mechanism". Mechanism".
Section 10 -- Appendix B Appendix B
Section 10.1 is the "example template" that was "Section 5" in Section B.1 is the "example template" that was "Section 5" in RFC
RFC2611. 2611.
Update the sample "declared registrant" data per the changes to the Update the sample "declared registrant" data per the changes to the
template description. template description.
Removed the reference to "US-ASCII" in the "namespace specific Removed the reference to "US-ASCII" in the "namespace specific
string" of the example namespace. string" of the example namespace.
Section 10.2 (new) Section B.2 (new)
This added section is a step-by-step walkthrough of the process for This added section is a step-by-step walkthrough of the process for
registering Informal namespaces and Formal namespaces. registering Informal namespaces and Formal namespaces.
Authors' Addresses
Leslie L. Daigle
Thinking Cat Enterprises
EMail: leslie@thinkingcat.com
Dirk-Willem van Gulik
WebWeaving Internet Engineering
Nieuwsteeg 37A
2311 RZ Leiden
The Netherlands
URL: http://www.webweaving.org/
Email: dirkx@webweaving.org
Renato Iannella
IPR Systems Pty Ltd.
EMail: renato@iprsystems.com
Patrik Faltstrom
Cisco Systems Inc
170 W Tasman Drive SJ-13/2
San Jose CA 95134
USA
EMail: paf@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 112 change blocks. 
309 lines changed or deleted 281 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/