draft-ietf-urn-nid-req-05.txt   draft-ietf-urn-nid-req-06.txt 
Internet Draft Leslie L. Daigle Internet Draft Leslie L. Daigle
August 4, 1998 Bunyip Information Systems October 8, 1998 Bunyip Information Systems
draft-ietf-urn-nid-req-05.txt Dirk-Willem van Gulik draft-ietf-urn-nid-req-06.txt Dirk-Willem van Gulik
ISIS/CEO, JRC Ispra ISIS/CEO, JRC Ispra
Renato Iannella Renato Iannella
DSTC Pty Ltd DSTC Pty Ltd
Patrik Faltstrom Patrik Faltstrom
Tele2/Swipnet Tele2/Swipnet
URN Namespace Definition Mechanisms URN Namespace Definition Mechanisms
Status of this Document Status of this Document
skipping to change at line 29 skipping to change at line 29
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- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as Drafts as reference material or to cite them other than as
"work in progress." "work in progress."
To view the entire list of current Internet-Drafts, please check To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
Coast), or ftp.isi.edu (US West Coast). Coast), or ftp.isi.edu (US West Coast).
0.0 Abstract 0.0 Abstract
The URN WG has defined a syntax for Uniform Resource Names The URN WG has defined a syntax for Uniform Resource Names
(URNs) [RFC2141], as well as some proposed mechanisms for their (URNs) [RFC2141], as well as some proposed mechanisms for their
resolution and use in Internet applications ([RFC2168, RFC2169]). resolution and use in Internet applications ([RFC2168, RFC2169]).
The whole rests on the concept of individual 'namespaces' within the The whole rests on the concept of individual "namespaces" within the
URN structure. Apart from proof-of-concept namespaces, the use URN structure. Apart from proof-of-concept namespaces, the use
of existing identifiers in URNs has been discussed ([RFC2288]), of existing identifiers in URNs has been discussed ([RFC2288]),
and this document lays out general definitions of and and this document lays out general definitions of and
mechanisms for establishing URN 'namespaces'. mechanisms for establishing URN "namespaces".
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 line 95 skipping to change at line 95
. (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, ISBNs and ISSNs are both collections of identifiers used
in the traditional publishing world; while there may some number (or in the traditional publishing world; while there may some number (or
numbers) that is both a valid ISBN identifier and ISSN identifier, numbers) that is both a valid ISBN identifier and ISSN identifier,
using different designators for the two collections ensures that no using different designators for the two collections ensures that no
two URNs will be the same for different resources. two URNs will be the same for different resources.
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 needs of identifiers, is a process that is inherently dependent on the
of the identifiers, how they will be assigned, and the uses to which requirements of the community defining the identifier, how they will
they will be put. All of these issues are specific to the individual be assigned, and the uses to which they will be put. All of these
community seeking to define a namespace (e.g., publishing community, issues are specific to the individual community seeking to define a
association of booksellers, protocol developers, etc); they are beyond namespace (e.g., publishing community, association of booksellers,
the scope of the IETF URN work. protocol developers, etc); they are beyond the scope of the IETF
URN work.
This document outlines the processes by which a collection of This document outlines the processes by which a collection of
identifiers satisfying certain constraints (uniqueness of assignment, identifiers satisfying certain constraints (uniqueness of assignment,
etc) can become a bona fide URN namespace by obtaining a NID. In a etc) can become a bona fide URN namespace by obtaining a NID. In a
nutshell, a template for the definition of the namespace is completed nutshell, a template for the definition of the namespace is completed
for deposit with IANA, and a NID is assigned. The details of the for deposit with IANA, and a NID is assigned. The details of the
process and possibilities for NID strings are outlined below; first, a process and possibilities for NID strings are outlined below; first, a
template for the definition is provided. template for the definition is provided.
3.0 URN Namespace Definition Template 3.0 URN Namespace Definition Template
skipping to change at line 133 skipping to change at line 134
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.
Information in the template is as follows: Information in the template is as follows:
Namespace ID: Namespace ID:
Assigned by IANA. In some contexts, a particular one Assigned by IANA. In some contexts, a particular one
may be requested (see below). may be requested (see below).
Registration Information:
This is information to identify the particular version of
registration information:
. registration version number: starting with 1, incrementing by 1
with each new version
. registration date: date submitted to the IANA, using
the format
YYYY-MM-DD
as outlined in [ISO8601].
Declared registrant of the namespace: Declared registrant of the namespace:
Name and e-mail address. Required: Name and e-mail address.
Recommended: Affiliation, address, etc.
Declaration of structure: Declaration of syntactic structure:
This section should outline any structural features of This section should outline any structural features of
identifiers in this namespace. At the very least, this identifiers in this namespace. At the very least, this
description may be used to introduce terminology used in description may be used to introduce terminology used in
other sections. This structure may also be used for other sections. This structure may also be used for
determining realistic caching/shortcuts approaches; suitable determining realistic caching/shortcuts approaches; suitable
caveats should be provided. caveats should be provided. If there are any specific
character encoding rules (e.g., which character should
always be used for single-quotes), these should be listed
here.
Answers might include, but are not limited to: Answers might include, but are not limited to:
. the structure is opaque (no exposition) . the structure is opaque (no exposition)
. a regular expression for parsing the identifier into . a regular expression for parsing the identifier into
components, including naming authorities components, including naming authorities
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 community's (e.g., ISO) documents outlining syntax . Other of the defining community's (e.g., ISO) documents
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 This section should address the requirement that
URN identifiers be assigned uniquely -- they are assigned URN identifiers be assigned uniquely -- they are assigned
to at most one resource, and are not reassigned. to at most one resource, and are not reassigned.
(Note that the definition of "resource" is fairly
broad; for example, information on "Today's Weather" might
be considered a single resource, although the content is
dynamic.)
Possible answers include, but are not limited to: Possible answers include, but are not limited to:
. exposition of the structure of the identifiers, and . exposition of the structure of the identifiers, and
partitioning of the space of identifiers amongst partitioning of the space of identifiers amongst
assignment authorities assignment authorities which are individually responsible
for respecting uniqueness rules
. identifiers are assigned sequentially . identifiers are assigned sequentially
. information is withheld; the namespace is opaque . information is withheld; the namespace is opaque
Identifier persistence considerations: Identifier persistence considerations:
Although non-reassignment of URN identifiers ensures Although non-reassignment of URN identifiers ensures
that a URN will persist in identifying a particular that a URN will persist in identifying a particular
resource even after the "lifetime of the resource", resource even after the "lifetime of the resource",
some consideration should be given to the persistence some consideration should be given to the persistence
of the usability of the URN. This is particularly of the usability of the URN. This is particularly
skipping to change at line 234 skipping to change at line 257
. the namespace is not listed with an RDS; this is not . the namespace is not listed with an RDS; this is not
relevant relevant
. resolution mirroring is completely open, with a mechanism . resolution mirroring is completely open, with a mechanism
for updating an appropriate RDS for updating an appropriate RDS
. resolution is controlled by entities to which assignment . resolution is controlled by entities to which assignment
has been delegated has been delegated
Rules for Lexical Equivalence: Rules for Lexical Equivalence:
If there are particular algorithms for determining If there are particular algorithms for determining
equivalence between two URN strings in this namespace, equivalence between two identifiers in the underlying
rules can be provided here. namespace (hence, in the URN string itself), rules can
be provided here.
Some examples include: Some examples include:
. mappings between different character set encodings
. equivalence between hyphenated and non-hyphenated . equivalence between hyphenated and non-hyphenated
groupings in the identifier string groupings in the identifier string
. equivalence between single-quotes and double-quotes
. Namespace-defined equivalences between specific
characters, such as "character X with or without
diacritic marks".
Note that these are not normative statements for any kind of
best practice for handling equivalences between characters;
they are statements limited to reflecting the namespace's
own rules.
Conformance with URN Syntax: Conformance with URN Syntax:
This section should outline any special considerations This section should outline any special considerations
required for conforming with the URN syntax. This is required for conforming with the URN syntax. This is
particularly applicable in the case of legacy naming particularly applicable in the case of legacy naming
systems that are used in the context of URNs. systems that are used in the context of URNs.
For example, if a namespace is used in contexts other For example, if a namespace is used in contexts other
than URNs, it may have a more generous character set than is than URNs, it may make use of characters that are reserved
immediately available with URNs. This section should flag this in the URN syntax. This section should flag any such
issue and outline necessary mappings to conform to characters, and outline necessary mappings to conform to
URN syntax. (E.g., see the section on SICIs in [RFC2288]). URN syntax. Normally, this will be handled by hex encoding
the symbol.
For example, see the section on SICIs in [RFC2288].
Validation mechanism: Validation mechanism:
Apart from attempting resolution of a URN, a URN namespace Apart from attempting resolution of a URN, a URN namespace
may provide mechanism for "validating" a URN -- i.e., may provide mechanism for "validating" a URN -- i.e.,
determining whether a given string is currently a determining whether a given string is currently a
validly-assigned URN. For example, even if an ISBN validly-assigned URN. For example, even if an ISBN
URN namespace is created, it is not clear that URN namespace is created, it is not clear that
all ISBNs will translate directly into "assigned URNs". all ISBNs will translate directly into "assigned URNs".
skipping to change at line 284 skipping to change at line 319
identifiers in this namespace. Apart from considerations identifiers in this namespace. Apart from considerations
of private vs. public namespaces, this section is critical of private vs. public namespaces, this section is critical
in evaluating the applicability of a requested NID. For in evaluating the applicability of a requested NID. For
example, a namespace claiming to deal in "social security example, a namespace claiming to deal in "social security
numbers" should have a global scope and address all numbers" should have a global scope and address all
social security number structures (unlikely). On the social security number structures (unlikely). On the
other hand, at a national level, it is reasonable to other hand, at a national level, it is reasonable to
posit a URN namespace for "this nation's social security posit a URN namespace for "this nation's social security
numbers". numbers".
4.0 URN Namespace Registration 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 According to the level of open-forum discussion surrounding
the disclosure, a URN namespace may be assigned or may request a the disclosure, a URN namespace may be assigned or may request a
particular identifier. particular identifier. The [IANA-CONSIDERATIONS] document suggests
the need to specify update mechanisms for registrations -- 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
(if any) changes should be made to the structural interpretation of
URN strings (e.g., adding or removing rules for lexical equivalence that
might affect the interpretation of URN IDs already assigned). However, it
may be important to introduce clarifications, expand the list of
authorized URN assigners, etc, over the natural course of a namespace's
lifetime. Specific processes are outlined below.
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 registration. by expected level of service and required procedures for registration.
Furthermore, registration maintenance procedures vary slightly from
one category to another.
I. Experimental: These are not explicitly registered with IANA. They I. Experimental: These are not explicitly registered with IANA. They
take the form take the form
x-<NID> x-<NID>
No provision is made for avoiding collision of experimental No provision is made for avoiding collision of experimental
NIDs; they are intended for use within internal or limited NIDs; they are intended for use within internal or limited
experimental contexts. experimental contexts.
As there is no registration, no registration maintenance
procedures are needed.
II. Informal: These are registered with IANA and are assigned a II. Informal: These are registered with IANA and are assigned a
number sequence as an identifier, in the format: number sequence as an identifier, in the format:
"iana-" <number> "iana-" <number>
where <number> is chosen by the IANA on a First Come First where <number> is chosen by the IANA on a First Come First
Served basis (see [IANA-CONSIDERATIONS]). Served basis (see [IANA-CONSIDERATIONS]).
Registrants should send a copy of the registration Registrants should send a copy of the registration
template (see section 3.0), duly completed, to the template (see section 3.0), duly completed, to the
skipping to change at line 332 skipping to change at line 381
submitted to: 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 The only restrictions on <number> are that it consist
strictly of digits and that it not cause the NID to exceed strictly of digits and that it not cause the NID to exceed
length limitations outlined in the URN syntax ([RFC2168]). length limitations outlined in the URN syntax ([RFC2168]).
Registrations may be updated by the original registrant,
or an entity designated by the registrant, by updating
the registration template, submitting it to the discussion
list for a further 2 week discussion period, and finally
resubmitting it to IANA, as described above.
III. Formal: These are processed through an RFC review III. Formal: These are processed through an RFC review
process. The RFC need not be standards-track. The template process. The RFC need not be standards-track. The
defined in section 3.0 may be template defined in section 3.0 may be included as part
included as part of the RFC, or a separate message of an RFC defining some other aspect of the namespace,
referencing the RFC. The proposed template should or it may be put forward as an RFC in its own right.
be sent to the The proposed template 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. mailing list to allow for a 2 week discussion period for
clarifying the expression of the registration information,
The registration template should then be sent to before the IESG progresses the document to RFC status.
iana@iana.org
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 [IANA-CONSIDERATIONS]), with consensus (as defined in [IANA-CONSIDERATIONS]), with
the additional constraints that the NID string must the additional constraints that the NID string must
not start with "x-" (see Type I above) or "iana-" (see Type II not start with "x-" (see Type I above) or "iana-" (see Type II
above), and is not already a registered NID. above), is not already a registered NID, and is more
than 2 letters long.
The two-letter country codes are reserved ALL two-letter combinations are reserved for use
for availability for national registrations. as country code NIDs for eventual national registrations of
URN namespaces.
Registrations may be updated by updating the RFC through
standard IETF RFC update mechanisms. Thus, proposals for
updates may be made by the original authors, other IETF
participants, or the IESG. In any case, the proposed
updated template must be circulated on the urn-nid
discussion list, allowing for a 2 week review period.
URN namespace registrations will be posted in the anonymous FTP directory URN namespace registrations will be posted in the anonymous FTP directory
"ftp://ftp.isi.edu/in-notes/iana/assignments/URN-namespaces/". "ftp://ftp.isi.edu/in-notes/iana/assignments/URN-namespaces/".
5.0 Example 5.0 Example
The following example is provided for the purposes of illustration of The following example is provided for the purposes of illustration of
the URN NID template described in section 3.0. Although it is based on the URN NID template described in section 3.0. Although it is based on
a posited "generic Internet namespace" that has been discussed informally a posited "generic Internet namespace" that has been discussed informally
within the URN WG, there are still technical and infrastructural issues within the URN WG, there are still technical and infrastructural issues
that would have to be resolved before such a namespace could be properly that would have to be resolved before such a namespace could be properly
and completely described. and completely described.
Namespace ID: Namespace ID:
To be assigned To be assigned
Registration Information:
Version 1
Date: <when submitted>
Declared registrant of the namespace: Declared registrant of the namespace:
T. Cat Required: Name and e-mail address.
leslie@thinkingcat.com 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: Declaration of structure:
The identifier structure is as follows: The identifier structure is as follows:
URN:<assigned number>:<FQDN>:<assigned string> URN:<assigned number>:<FQDN>:<assigned US-ASCII string>
where FQDN is a fully-qualified domain name, and the where FQDN is a fully-qualified domain name, and the
assigned string is conformant to URN syntax requirements. assigned 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. RFC1035, November 1987.
skipping to change at line 460 skipping to change at line 535
6.0 Security Considerations 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 should be of relatively low security profile, however there is
always the danger of "spoofing" and providing mis-information. always the danger of "spoofing" and providing mis-information.
Information in these declarations should be taken as advisory. Information in these declarations should be taken as advisory.
7.0 References 7.0 References
[IANA-CONSIDERATIONS] H. Alvestrand and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs",
draft-iesg-iana-considerations-04.txt.
[RFC2168] Ron Daniel & Michael Mealling, "Resolution of Uniform [RFC2168] Ron Daniel & Michael Mealling, "Resolution of Uniform
Resource Identifiers using the Domain Name System", RFC 2168, Resource Identifiers using the Domain Name System", RFC 2168,
June 1997. June 1997.
[RFC2169] Ron Daniel, "A Trivial Convention for using HTTP in URN [RFC2169] Ron Daniel, "A Trivial Convention for using HTTP in URN
Resolution", RFC 2169, June 1997. Resolution", RFC 2169, June 1997.
[ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange formats -
Information interchange - Representation of dates and times"
[RFC2288] C. Lynch, C. Preston & R. Daniel, "Using Existing [RFC2288] C. Lynch, C. Preston & R. Daniel, "Using Existing
Bibliographic Identifiers as Uniform Resource Names", RFC 2288, Bibliographic Identifiers as Uniform Resource Names", RFC 2288,
February 1998. February 1998.
[NAPTR-REG] M. Mealling, "Assignment Procedures for the URI Resolution [NAPTR-REG] M. Mealling, "Assignment Procedures for the URI Resolution
using DNS (RFC2168)", draft-ietf-urn-net-procedures-00.txt. using DNS (RFC2168)", draft-ietf-urn-net-procedures-00.txt.
[RFC2141] Ryan Moats, "URN Syntax", RFC 2141, May 1997. [RFC2141] Ryan Moats, "URN Syntax", RFC 2141, May 1997.
[IANA-CONSIDERATIONS] T. Narten and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
draft-iesg-iana-considerations-06.txt.
[RFC1737] Karen R Sollins & Larry Masinter, "Functional Requirements [RFC1737] Karen R Sollins & Larry Masinter, "Functional Requirements
for Uniform Resource Names", RFC1737, December 1994 for Uniform Resource Names", RFC1737, December 1994
[RFC2276] K. Sollins, "Architectural Principles of Uniform Resource [RFC2276] K. Sollins, "Architectural Principles of Uniform Resource
Name Resolution", RFC 2276, January 1998. Name Resolution", RFC 2276, January 1998.
8.0 Authors' Addresses 8.0 Authors' Addresses
Leslie L. Daigle Leslie L. Daigle
Bunyip Information Systems Inc Bunyip Information Systems Inc
 End of changes. 31 change blocks. 
46 lines changed or deleted 124 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/