draft-ietf-urn-rfc2611bis-02.txt   draft-ietf-urn-rfc2611bis-03.txt 
Internet-Draft L. Daigle Internet-Draft L. Daigle
URN WG Thinking Cat Enterprises URN WG Thinking Cat Enterprises
Expires September 1, 2001 D. van Gulik Expires November 7, 2001 D. van Gulik
Category: Best Current Practice WebWeaving Category: Best Current Practice WebWeaving
draft-ietf-urn-rfc2611bis-02.txt R. Iannella draft-ietf-urn-rfc2611bis-03.txt R. Iannella
IPR Systems IPR Systems
P. Faltstrom P. Faltstrom
Cisco Cisco
March 1, 2001 May 7, 2001
URN Namespace Definition Mechanisms 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 is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 29 skipping to change at page 1, line 29
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The URN WG has defined a syntax for Uniform Resource Names (URNs) The URN WG has defined a syntax for Uniform Resource Names (URNs)
[RFC2141], as well as some proposed mechanisms for their resolution [RFC2141], as well as some proposed mechanisms for their resolution
and use in Internet applications ([RFCXXXX], [RFCYYYY]). The whole and use in Internet applications ([RFCXXXX], [RFCYYYY]). The whole
rests on the concept of individual "namespaces" within the URN rests on the concept of individual "namespaces" within the URN
skipping to change at page 3, line 18 skipping to change at page 3, line 18
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 [RFCXXXX], is necessary. See [RFCYYYY] 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. A URN namespace itself has an identifier in assigned identifiers. That is, the identifiers are not ever assigned
order to 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
assigned to it for different purposes. 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 - (where desired) provide a cue for the structure of the
identifier identifier
For example, ISBNs and ISSNs are both collections of identifiers used For example, many identifier systems make use strings of numbers as
in the traditional publishing world; while there may be some number identifiers (e.g., ISBN, ISSN, phone numbers). It is conceivable that
(or numbers) that is both a valid ISBN identifier and ISSN there might be some numbers that are valid identifiers in two
identifier, using different designators for the two collections different established identifier systems. Using different
ensures that no two URNs will be the same for different resources. designators for the two collections ensures that no two URNs will be
the same for different resources (since each collection is required
to uniquely assign each identifier).
The development of an identifier structure, and thereby a collection 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, etc); they are beyond the scope of the IETF URN
work. 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; first, process and possibilities for NID strings are outlined below.
a template for the definition is provided.
3.0 URN Namespace (Registration) Types 3.0 URN Namespace (Registration) Types
There are 3 categories of URN namespaces defined here, distinguished There are 3 categories of URN namespaces defined here, distinguished
by expected level of service and required procedures for by expected level of service and required procedures for
registration. Registration processes for each of these namespace 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>
skipping to change at page 4, line 25 skipping to change at page 4, line 28
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
uphold the general principles of a well-managed URN namespace -- uphold the general principles of a well-managed URN namespace --
providing persistent, unique identification of resources. Informal providing persistent identification of resources, and unique
and formal namespaces (described below) differ in the NID assignment. assignment of identifier strings. Informal and formal namespaces
IANA will assign an alphanumeric NID to registered informal (described below) differ in the NID assignment. IANA will assign an
namespaces, per the process outlined in Section 4.0. alphanumeric NID to registered informal namespaces, per the process
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, a
NID is requested that is meant for naming of physics research. If NID is requested that is meant for naming of physics research. If
that NID request required that the user use a propietary network or that NID request required that the user use a propietary 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 it
would make a poor request for a formal NID. The intent is that, while would make a poor request for a formal NID. The intent is that, while
the community of those who may actively use the names assigned within the community of those who may actively use the names assigned within
that NID may be small (but no less important), the potential use of that NID may be small (but no less important), the potential use of
names within that NID is open to any user on the Internet. 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 an privately managed (proprietary) registry (as, e.g., ISBN use of a fee-based, privately managed, or proprietary registry for
does), for assignment of URNs in the namespace, but it may still assignment of URNs in the namespace, but it may still provide benefit
provide benefit to some Internet users if the services associated to some Internet users if the services associated have openly-
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 the community benefit of formally establishing the
proposed URN namespace. 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
skipping to change at page 6, line 23 skipping to change at page 6, line 24
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 "ftp://ftp.isi.edu/in- anonymous FTP directory
notes/iana/assignments/URN-namespaces/". See [STD2] for the current
location of IANA registry. ftp://ftp.isi.edu/in-notes/iana/assignments/URN-namespaces/
See [STD2] 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>
skipping to change at page 7, line 13 skipping to change at page 7, line 19
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 the
urn-nid@apps.ietf.org urn-nid@apps.ietf.org
mailing and allow for a 2 week discussion period for clarifying the mailing 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
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 to:
iana@iana.org iana@iana.org
for assignment of a NID. for assignment of a NID.
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
skipping to change at page 9, line 11 skipping to change at page 9, line 18
- be more than 2 letters long - 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 for potential use as countrycode- based NIDs for eventual reserved for potential use as countrycode- based NIDs for eventual
national registrations of URN namespaces. The definition and national registrations of URN namespaces. The definition and
scoping of rules for allocation of responsibility for such namespaces scoping of rules for allocation of responsibility for such namespaces
is beyond the scope of this document. is beyond the 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 mechanisms. Thus, proposals for updates may be made IETF RFC update processes (see [RFC2606] for a discussion of IETF
by the original authors, other IETF participants, or the IESG. In process). In any case, a revised document, in the form of a new
any case, the proposed updated template must be circulated on the Internet-Draft, must be published, and the proposed updated template
urn-nid discussion list, allowing for a 2 week review period. must be circulated on the urn-nid discussion list, allowing for a 2
week review period before pursuing publication of the new RFC
document.
5.0 Security Considerations 5.0 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 always
the danger of "spoofing" and providing mis-information. Information the danger of "spoofing" and providing mis-information. Information
in these declarations should be taken as advisory. in these declarations should be taken as advisory.
6.0 IANA Considerations 6.0 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. 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 replaces the processes outlined have been completed. This document defines processes to replace
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 - Information interchange - Representation of formats - Information interchange - Representation of
dates and times" dates and times"
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, October 1996.
[RFC2288] Lynch, C., Preston, C. and R. Daniel, "Using Existing [RFC2288] Lynch, C., Preston, C. and R. Daniel, "Using Existing
Bibliographic Identifiers as Uniform Resource Names", RFC Bibliographic Identifiers as Uniform Resource Names", RFC
2288, February 1998. 2288, February 1998.
[RFCXXXX] Mealling, M., "URI Resolution using the Dynamic [RFCXXXX] Mealling, M., "URI Resolution using the Dynamic
Delegation Discovery System", RFCXXXX. Delegation Discovery System", RFCXXXX.
[RFCYYYY] Mealling, M., "Assignment Procedures for URI Resolution [RFCYYYY] Mealling, M., "Assignment Procedures for URI Resolution
Using DNS", RFCYYYY. Using DNS", RFCYYYY.
skipping to change at page 11, line 23 skipping to change at page 11, line 33
- 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
Considerations", "Community Considerations" and "IANA
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, Assigned by IANA. In the case of a Formal NID registration,
a particular NID string may be requested. 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:
skipping to change at page 14, line 40 skipping to change at page 15, line 5
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 provide mechanism for "validating" a URN -- i.e., determining
whether a given string is currently a validly-assigned URN. For whether a given string is currently a validly-assigned URN.
example, even if an ISBN URN namespace is created, it is not clear There are 2 issues here: 1) users should not "guess" URNs in a
that all ISBNs will translate directly into "assigned URNs". namespace; 2) when the URN namespace is based on an existing
identifier system, it may not be the case that all the existing
identifiers are assigned on Day 0. The reasonable expectation is
that the
resource associated with each resulting URN is somehow related to
the
thing identified by the original identifier system, but those
resources may not exist for each original identifier. For
example, even if a telephone number-based URN namespace was
created,
it is not clear that all telephone numbers would immediately
become
"valid" URNs, that could be resolved using whatever mechanisms
are described as part of the namespace registration.
A validation mechanims might be: A validation mechanims 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
skipping to change at page 17, line 39 skipping to change at page 18, line 19
3. Update the registration template as necessary from comments, and 3. Update the registration template as necessary from comments, and
repeat steps 2 and 3 as necessary. 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) end 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 including
the registration template, duly completed. the registration template, duly completed. Be sure to include
"Namespace Considerations", "Community Considerations" and "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 repeat
steps 2 and 3 as needed. 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
 End of changes. 19 change blocks. 
35 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/