draft-ietf-urn-rfc2611bis-00.txt   draft-ietf-urn-rfc2611bis-01.txt 
Internet-Draft L. Daigle Internet-Draft L. Daigle
URN WG Thinking Cat Enterprises URN WG Thinking Cat Enterprises
Expires May 11, 2001 D. van Gulik Expires August 11, 2001 D. van Gulik
Category: Best Current Practice WebWeaving Category: Best Current Practice WebWeaving
draft-ietf-urn-rfc2611bis-00.txt R. Iannella draft-ietf-urn-rfc2611bis-01.txt R. Iannella
DSTC Pty Ltd IPR Systems
P. Faltstrom P. Faltstrom
Cisco Cisco
November 10, 2000 February 11, 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 2, line 7 skipping to change at page 2, line 7
existing identifiers in URNs has been discussed ([RFC2288]), and this existing identifiers in URNs has been discussed ([RFC2288]), and this
document lays out general definitions of and mechanisms for document lays out general definitions of and mechanisms for
establishing URN "namespaces". establishing URN "namespaces".
This document obsoletes RFC2611. This document obsoletes RFC2611.
Discussion of this document should be directed to urn-ietf@ietf.org Discussion of this document should be directed to urn-ietf@ietf.org
Table of Contents Table of Contents
Abstract ........................................................ 1 Abstract ........................................................
Table of Contents ............................................... 2 Table of Contents ...............................................
1.0 Introduction ................................................ 2 1.0 Introduction ................................................
2.0 What is a URN Namespace? .................................... 3 2.0 What is a URN Namespace? ....................................
3.0 URN Namespace (Registration) Types .......................... 3 3.0 URN Namespace (Registration) Types ..........................
3.1 Experimental Namespaces .................................... 4 3.1 Experimental Namespaces .....................................
3.2 Informal Namespaces ......................................... 4 3.2 Informal Namespaces .........................................
3.3 Formal Namespaces ........................................... 4 3.3 Formal Namespaces ...........................................
4.0 URN Namespace Registration, Update, and NID Assignment 4.0 URN Namespace Registration, Update, and NID Assignment
Process ..................................................... 5 Process .....................................................
4.1 Experimental ................................................ 5 4.1 Experimental ................................................
4.2 Informal .................................................... 6 4.2 Informal ....................................................
4.3 Formal ...................................................... 6 4.3 Formal ......................................................
5.0 Illustration ................................................ 8 5.0 Security Considerations .....................................
5.1 Example Template ............................................ 8 6.0 IANA Considerations .........................................
5.1 Registration steps in practice .............................. 10 7.0 References ..................................................
6.0 Security Considerations ..................................... 11 8.0 Authors' Addresses ..........................................
7.0 IANA Considerations ......................................... 11 9.0 Appendix A -- URN Namespace Definition Template .............
8.0 References .................................................. 11 10.0 Appendix B -- Illustration .................................
9.0 Authors' Addresses .......................................... 12 10.1 Example Template ...........................................
10.0 Appendix -- URN Namespace Definition Template .............. 13 10.2 Registration steps in practice .............................
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.
There are 2 assumptions that are key to this document: There are 2 assumptions that are key to this document:
Assumption #1: Assumption #1:
skipping to change at page 3, line 48 skipping to change at page 4, line 4
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; first,
a template for the definition is provided. 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, 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
skipping to change at page 4, line 36 skipping to change at page 4, line 37
IANA will assign an alphanumeric NID to registered informal IANA will assign an alphanumeric NID to registered informal
namespaces, per the process outlined in Section 4.0. 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 an open and broad base of the namespace will provide benefit to an open and broad base of the
Internet community. That is, as in any open standards outcome, Internet community. That is, as in any open standards outcome,
publication of the NID proposal would allow persons not immediately publication of the NID proposal would allow persons not immediately
associated with the proposer to create new software, or services, or associated with the proposer to work with the identifiers, or
otherwise better carry out their own activities than if the NID otherwise better carry out their own activities than if the NID
publication had not been made. Benefits are expected to be in the publication had not been made. Benefits are expected to be in the
form of open accessibility, interoperability, etc. form of open accessibility, interoperability, etc.
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 externally managed (proprietary) registry (as, e.g., ISBN use of an externally managed (proprietary) registry (as, e.g., ISBN
does), for assignment of URNs in the namespace, but it may still does), for assignment of URNs in the namespace, but it may still
provide broad community benefit if the services associated have provide broad community benefit if the services associated have
openly-published access protocols. openly-published access protocols.
In addition to the basic registration information defined in the In addition to the basic registration information defined in the
registration template (in the Appendix), 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
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 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
in order to facilitate persistence (e.g. to minimize the
likelihood of conflicts);
- it should commit to not re-assigning existing names and allowing
old names to continue to be valid, even if the owners or
assignees of those names are no longer members or customers of
that organization. This does not mean that there must be
resolution of such names, but it does mean that they must not
resolve the name to false or stale information, and it means
that they must not be reassigned.
These aspects, though hard to quantify objectively, should be
considered by organizations/people considering the development of a
Formal URN namespace, and they will be kept in mind when evaluating
the technical merits of any proposed Formal 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
skipping to change at page 5, line 38 skipping to change at page 6, line 18
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.
URN namespace registrations will be posted in the anonymous FTP The official list of registered URN namespaces is maintained by IANA.
directory "ftp://ftp.isi.edu/in-notes/iana/assignments/URN- URN namespace registrations are currently being posted in the
namespaces/". anonymous FTP directory "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>
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
skipping to change at page 6, line 23 skipping to change at page 6, line 50
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 the Registrants should send a copy of the registration template (see
Appendix), 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. 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:
skipping to change at page 7, line 16 skipping to change at page 7, line 42
"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 prospective assignments from appropriate persons input on prospective assignments from appropriate persons
(e.g., a relevant Working Group if one exists)." (e.g., a relevant 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 the Appendix 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 2 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 resolution/delegation - URN assignment procedures
- type of resources to be identified - type of services to - URN resolution/delegation
be supported - type of resources to be identified
- 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 the Internet indicates the dimensions upon which the proposer expects the Internet
community to be able to benefit by publication of this namespace. community to be able to benefit by publication of this namespace.
Potential considerations include: Potential considerations include:
- open assignment and use of identifiers within the namespace - open assignment and use of identifiers within the namespace
- open operation of resolution servers for the namespace - open operation of resolution servers for the namespace
(server) - creation of software that can meaningfully resolve (server)
and access services for the namespace (client) - creation of software that can meaningfully resolve and
access services for the namespace (client)
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-" - not be an already-registered NID
(see Type I above) - not start with "urn-" (see Type II above) - not start with "x-" (see Type I above)
- not start with "urn-" (see Type II above)
- not start with "XY-", where XY is any combination of 2 - not start with "XY-", where XY is any combination of 2
ASCII letters (see NOTE, below) - be more than 2 letters long ASCII 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 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 mechanisms. Thus, proposals for updates may be made
by the original authors, other IETF participants, or the IESG. In by the original authors, other IETF participants, or the IESG. In
any case, the proposed updated template must be circulated on the any case, the proposed updated template must be circulated on the
urn-nid discussion list, allowing for a 2 week review period. urn-nid discussion list, allowing for a 2 week review period.
5.0 Illustration 5.0 Security Considerations
5.1 Example Template
The following example is provided for the purposes of illustration of
the URN NID template described in the Appendix. Although it is based
on a hypothetical "generic Internet namespace" that has been
discussed informally within the URN WG, there are still technical and
infrastructural issues that would have to be resolved before such a
namespace could be properly and completely described.
Namespace ID:
To be assigned
Registration Information:
Version 1
Date: <when submitted>
Declared registrant of the namespace:
Required: Name and e-mail address.
Recommended: Affiliation, address, etc.
Declared registrant of the namespace:
Name: T. Cat
E-mail: leslie@thinkingcat.com
Affiliation: Thinking Cat Enterprises
Address: 1 ThinkingCat Way
Trupville, NewCountry
Declaration of structure:
The identifier structure is as follows:
URN:<assigned number>:<FQDN>:<assigned US-ASCII string>
where FQDN is a fully-qualified domain name, and the assigned
string is conformant to URN syntax requirements.
Relevant ancillary documentation:
Definition of domain names, found in:
P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
RFC1035, November 1987.
Identifier uniqueness considerations:
Uniqueness is guaranteed as long as the assigned string is never
reassigned for a given FQDN, and that the FQDN is never
reassigned.
N.B.: operationally, there is nothing that prevents a domain name
from being reassigned; indeed, it is not an uncommon occurrence.
This is one of the reasons that this example makes a poor URN
namespace in practice, and is therefore not seriously being
proposed as it stands.
Identifier persistence considerations:
Persistence of identifiers is dependent upon suitable delegation
of resolution at the level of "FQDN"s, and persistence of FQDN
assignment.
Same note as above.
Process of identifier assignment:
Assignment of these URNs delegated to individual domain name
holders (for FQDNs). The holder of the FQDN registration is
required to maintain an entry (or delegate it) in the DDDS.
Within each of these delegated name partitions, the string may be
assigned per local requirements.
e.g. urn:<assigned number>:thinkingcat.com:001203
Process for identifier resolution:
Domain name holders are responsible for operating or delegating
resolution servers for the FQDN in which they have assigned URNs.
Rules for Lexical Equivalence:
FQDNs are case-insensitive. Thus, the portion of the URN
urn:<assigned number>:<FQDN>:
is case-insenstive for matches. The remainder of the identifier
must be considered case-sensitve.
Conformance with URN Syntax:
No special considerations.
Validation mechanism:
None specified.
Scope:
Global.
5.1 Registration steps in practice
The key steps for registration of informal or formal namespaces
typically play out as follows:
Informal NID:
1. Complete the registration template. This may be done as part
of an Internet-Draft.
2. Communicate the registration template to urn-nid@apps.ietf.org
for technical review -- as a published I-D, or text e-mail message
containing the template.
3. Update the registration template as necessary from comments, and
repeat steps 2 and 3 as necessary.
4. Once comments have been addressed (and the review period has
expired) end a request to IANA with the revised registration
template.
Formal NID:
1. Write an Internet-Draft describing the namespace and including
the registration template, duly completed.
2. Send the Internet-Draft to the I-D editor, and send a copy to
urn-nid@apps.ietf.org for technical review.
3. Update the Internet-Draft as necessary from comments, and repeat
steps 2 and 3 as needed.
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)
and/or direct discussion to designated working groups, area
experts, etc.
5. If the IESG approves the document for publication as an RFC,
send a request to IANA to register the requested NID.
6.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.
7.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. have been completed.
8.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"
[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.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. 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 [RFC2276] Sollins, K., "Architectural Principles of Uniform
Resource Name Resolution", RFC 2276, January 1998. Resource Name Resolution", RFC 2276, January 1998.
9.0 Authors' Addresses 8.0 Authors' Addresses
Leslie L. Daigle Leslie L. Daigle
Thinking Cat Enterprises Thinking Cat Enterprises
EMail: leslie@thinkingcat.com EMail: leslie@thinkingcat.com
Dirk-Willem van Gulik Dirk-Willem van Gulik
WebWeaving WebWeaving
Plein 1813 - 5a Plein 1813 - 5a
8545 HX Arnhem 8545 HX Arnhem
The Netherlands The Netherlands
Phone: +39 0332 78 0014 (Phone and Fax) Phone: +39 0332 78 0014 (Phone and Fax)
EMail: Dirkx@webweaving.org EMail: Dirkx@webweaving.org
Renato Iannella Renato Iannella
DSTC Pty Ltd IPR Systems Pty Ltd.
Gehrmann Labs, The Uni of Queensland
AUSTRALIA, 4072
Phone: +61 7 3365 4310 EMail: renato@iprsystems.com
Fax: +61 7 3365 4311
EMail: renato@dstc.edu.au
Patrik Faltstrom Patrik Faltstrom
Cisco Systems Inc Cisco Systems Inc
170 W Tasman Drive SJ-13/2 170 W Tasman Drive SJ-13/2
San Jose CA 95134 San Jose CA 95134
USA USA
EMail: paf@cisco.com EMail: paf@cisco.com
URL: http://www.cisco.com URL: http://www.cisco.com
10.0 Appendix -- URN Namespace Definition Template 9.0 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)
skipping to change at page 14, line 5 skipping to change at page 11, line 33
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 YYYY-MM-DD
as outlined in [ISO8601]. as outlined in [ISO8601].
Declared registrant of the namespace: Declared registrant of the namespace:
This includes:
Required: Name and e-mail address. Registering organization
Recommended: Affiliation, address, etc. Name
Address
Designated contact person
Name
Coordinates (at least one of: e-mail, phone, postal address)
Declaration of syntactic structure: Declaration of syntactic structure:
This section should outline any structural features of identifiers This section should outline any structural features of identifiers
in this namespace. At the very least, this description may be in this namespace. At the very least, this description may be
used to introduce terminology used in other sections. This used to introduce terminology used in other sections. This
structure may also be used for determining realistic 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) - a regular expression
for parsing the identifier into components, including naming for parsing the identifier into components, including naming
authorities authorities
skipping to change at line 759 skipping to change at page 15, line 5
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
10.1 Example Template
The following example is provided for the purposes of illustration of
the URN NID template described in Appendix A. Although it is based
on a hypothetical "generic Internet namespace" that has been
discussed informally within the URN WG, there are still technical and
infrastructural issues that would have to be resolved before such a
namespace could be properly and completely described.
Namespace ID:
To be assigned
Registration Information:
Version 1
Date: <when submitted>
Declared registrant of the namespace:
Name: Thinking Cat Enterprises
Address: 1 ThinkingCat Way
Trupville, NewCountry
Contact: L. Daigle
E-mail: leslie@thinkingcat.com
Declaration of structure:
The identifier structure is as follows:
URN:<assigned number>:<FQDN>:<assigned string>
where FQDN is a fully-qualified domain name, and the assigned
string is conformant to URN syntax requirements.
Relevant ancillary documentation:
Definition of domain names, found in:
P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
RFC1035, November 1987.
Identifier uniqueness considerations:
Uniqueness is guaranteed as long as the assigned string is never
reassigned for a given FQDN, and that the FQDN is never
reassigned.
N.B.: operationally, there is nothing that prevents a domain name
from being reassigned; indeed, it is not an uncommon occurrence.
This is one of the reasons that this example makes a poor URN
namespace in practice, and is therefore not seriously being
proposed as it stands.
Identifier persistence considerations:
Persistence of identifiers is dependent upon suitable delegation
of resolution at the level of "FQDN"s, and persistence of FQDN
assignment.
Same note as above.
Process of identifier assignment:
Assignment of these URNs delegated to individual domain name
holders (for FQDNs). The holder of the FQDN registration is
required to maintain an entry (or delegate it) in the DDDS.
Within each of these delegated name partitions, the string may be
assigned per local requirements.
e.g. urn:<assigned number>:thinkingcat.com:001203
Process for identifier resolution:
Domain name holders are responsible for operating or delegating
resolution servers for the FQDN in which they have assigned URNs.
Rules for Lexical Equivalence:
FQDNs are case-insensitive. Thus, the portion of the URN
urn:<assigned number>:<FQDN>:
is case-insenstive for matches. The remainder of the identifier
must be considered case-sensitve.
Conformance with URN Syntax:
No special considerations.
Validation mechanism:
None specified.
Scope:
Global.
10.2 Registration steps in practice
The key steps for registration of informal or formal namespaces
typically play out as follows:
Informal NID:
1. Complete the registration template. This may be done as part
of an Internet-Draft.
2. Communicate the registration template to urn-nid@apps.ietf.org
for technical review -- as a published I-D, or text e-mail message
containing the template.
3. Update the registration template as necessary from comments, and
repeat steps 2 and 3 as necessary.
4. Once comments have been addressed (and the review period has
expired) end a request to IANA with the revised registration
template.
Formal NID:
1. Write an Internet-Draft describing the namespace and including
the registration template, duly completed.
2. Send the Internet-Draft to the I-D editor, and send a copy to
urn-nid@apps.ietf.org for technical review.
3. Update the Internet-Draft as necessary from comments, and repeat
steps 2 and 3 as needed.
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)
and/or direct discussion to designated working groups, area
experts, etc.
5. If the IESG approves the document for publication as an RFC,
send a request to IANA to register the requested NID.
 End of changes. 30 change blocks. 
203 lines changed or deleted 96 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/