draft-ietf-urn-nid-req-02.txt   draft-ietf-urn-nid-req-03.txt 
Internet Draft Leslie L. Daigle Internet Draft Leslie L. Daigle
November 19, 1997 Bunyip Information Systems March 11, 1998 Bunyip Information Systems
draft-ietf-urn-nid-req-02.txt Dirk-Willem van Gulik draft-ietf-urn-nid-req-03.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 Registration and Standardization Process Mechanisms URN Namespace Definition Mechanisms
Status of this Document Status of this Document
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-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- 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), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast). Coast), or ftp.isi.edu (US West Coast).
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 (??? biblio id of existing identifiers in URNs has been discussed ([RFC2288]),
document). This document lays out general definitions of and mechanisms and this document lays out general definitions of and
for establishing URN ''namespaces''. mechanisms for establishing URN ''namespaces''.
Foreword to this Edition 0.1 Foreword to this Edition
This document is a very drafty draft. The intention of this version For the purposes of this document, an "IANA-like" entity is assumed to
is to lay out the groundwork for some proposed processes. Detail will exist. Anywhere the term "IANA" appears, consider it a pointer to
be needed. No one has formally approached IANA to set up the registry whatever organization or entity exists to handle Internet
this is defining. The model here is not unlike media type registrations. registration/assignment tasks.
Introduction Still notably absent:
For the purposes of URNs, a "namespace" is a collection of uniquely-assigned . where to _send_ and/or _discuss_ the declarations
identifiers. A URN namespace itself has an identifier in order to defined here
. process mechanisms for assigning/obtaining specific NIDs.
These details must wait until there is general resolution re.
Internet assigned numbers.
1.0 Introduction
Uniform Resource Names (URNs) are resource identifiers with the
specific requirements for enabling location independent
identification of a resource, as well as longevity of reference.
There are 2 assumptions that are key to this document:
Assumption #1:
Assignment of a URN is a managed process.
I.e., not all strings that conform to URN syntax are necessarily
valid URNs. A URN is assigned according to the rules of a
particular namespace (in terms of syntax, semantics, and process).
Assumption #2:
The space of URN namespaces is managed.
I.e., not all syntactically correct URN namespaces (per the URN
syntax definition) are valid URN namespaces. A URN namespace
must have a recognized definition in order to be valid.
The purpose of this document is to outline a mechanism and provide a
template for explicit namespace definition, along with the mechanism
for associating an identifier (called a "Namespace ID", or NID) which
is registered with the IANA.
Note that this document restricts itself to the description of
processes for the creation of URN namespaces. If "resolution" of any
so-created URN identifiers is desired, a separate process of
registration in a global NID directory, such as that provided by the
NAPTR system [RFC2168], is necessary.
2.0 What is a URN Namespace?
For the purposes of URNs, a "namespace" is a collection of
uniquely-assigned identifiers. A URN namespace itself has an
identifier in order to
. ensure global uniqueness of URNs . ensure global uniqueness of URNs
. (where desired) provide a cue for the structure of the identifier . (where desired) provide a cue for the structure of the
identifier
For example, 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 numbers) in the traditional publishing world; while there may some number (or
that is both a valid ISBN identifier and ISSN identifier, using different numbers) that is both a valid ISBN identifier and ISSN identifier,
designators for the two collections ensures that no two URNs will be the same using different designators for the two collections ensures that no
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 needs
of the identifiers, how they will be assigned, and the uses to which they of the identifiers, how they will be assigned, and the uses to which
will be put. All of these issues are beyond the scope of the URN they will be put. All of these issues are specific to the individual
work. community seeking to define a namespace (e.g., publishing community,
association of booksellers, protocol developers, etc); they are beyond
the scope of the IETF URN work.
This document concerns itself with the mechanical processes of associating This document outlines the processes by which a collection of
an identifier string with a predefined namespace and publication of identifiers satisfying certain constraints (uniqueness of assignment,
identifier structures. Of particular concern are: 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
for deposit with IANA, and a NID is assigned. The details of the
process and possibilities for NID strings are outlined below; first, a
template for the definition is provided.
. selection of strings to associate with a namespace 3.0 URN Namespace Definition Template
. publication of structural elements of the identifiers
. identification of support infrastructure for assignment
and resolution of URNs for a given namespace
. determination of failure of support for a namespace
Different levels of disclosure are expected/defined for namespaces. Definition of a URN namespace is accomplished by completing the
According to the level of discussion and standardization surrounding the following information template. Apart from providing a mechanism
disclosure, a URN namespace may be assigned or may request a particular for disclosing structure of the URN namespace, this information
identifier. is designed to be useful for
Note that this document restricts itself to the description of processes . entities seeking to have a URN assigned in a namespace
for the creation of URN namespaces. If "resolution" of any so-created (if applicable)
URN identifiers is desired, a separate process of registration in a global . entities seeking to provide URN resolvers for a namespace
NID directory, such as that provided by the NAPTR [Ref ??] system, is (if applicable)
necessary.
URN Namespace Categories This is particularly important for communities evaluating the
possibility of using a portion of an existing URN namespace rather
than creating their own.
There are 4 categories of URN namespaces defined here, distinguished by Information in the template is as follows:
expected level of service and required procedures for registration.
The first three are simple namespace types: Namespace ID:
I. Experimental: These are not registered with IANA. They take the Assigned by IANA. In some contexts, a particular one
form may be requested (see below).
x-<NID>
II. Informal: These are registered with IANA (see Section ??), and Declared registrant of the namespace:
are assigned a number based on a private OID ("POID"
namespaces).
III. Standardized: These are processed through a full standards-track Name and e-mail address.
RFC review process. The NID may be any valid NID string
that does not clash with an existing, registered NID.
The fourth is a composite namespace type (i.e., one constructed for Declaration of structure:
the express purpose of later subdivision):
IV. Top-level: These are processed through a full standards-track This section should outline any structural features of
RFC review process. The result is not a NID so much identifiers in this namespace. At the very least, this
as a top-level NID structure, which will be subdivided by the description may be used to introduce terminology used in
rules laid out in the top-level NID RFC. These NID other sections. This structure may also be used for
strings must not clash with existing, registered NIDs; determining realistic caching/shortcuts approaches; suitable
additionally, the RFC1766 country code strings are caveats should be provided.
reserved for use by countries that desire to so-obtain
a top-level NID.
Registration Procedures Answers might include, but are not limited to:
To register a namespace (for type II namespaces, informal), the following . the structure is opaque (no exposition)
information must be provided to the IANA: . a regular expression for parsing the identifier into
components, including naming authorities
Declared owner of the namespace Identifier uniqueness considerations:
Description of:
This section should address the requirement that
URN identifiers be assigned uniquely -- they are assigned
to at most one resource, and are not reassigned.
Possible answers include, but are not limited to:
. exposition of the structure of the identifiers, and
partitioning of the space of identifiers amongst
assignment authorities
. identifiers are assigned sequentially
. information is withheld; the namespace is opaque
Identifier persistence considerations:
Although non-reassignment of URN identifiers ensures
that a URN will persist in identifying a particular
resource even after the "lifetime of the resource",
some consideration should be given to the persistence
of the usability of the URN. This is particularly
important in the case of URN namespaces providing
global resolution.
Possible answers include, but are not limited to:
. quality of service considerations
Process of identifier assignment:
This section should detail the mechanisms and or authorities
for assigning URNs to resources. It should make clear whether
assignment is completely open, or if limited, how
to become an assigner of identifiers, and/or get one
assigned by existing assignment authorities. Answers
could include, but are not limited to:
. assignment is completely open, following a particular
algorithm
. assignment is delegated to authorities recognized by
a particular organization (e.g., the Digital Object
Identifier Foundation controls the DOI assignment space and
its delegation)
. assignment is completely closed (e.g., for a private
organization)
Process for identifier resolution:
If a namespace is intended to be accessible for global
resolution, it must be registerd in an RDS (Resolution
Discovery System, see [RFC2276]) such as NAPTR. Resolution
then proceeds according to standard URI resolution processes,
and the mechanisms of the RDS. What this section should
outline is the requirements for becoming a recognized resolver
of URNs in this namespace (and being so-listed in the RDS
registry).
Answers may include, but are not limited to:
. the namespace is not listed with an RDS; this is not
relevant
. resolution mirroring is completely open, with a mechanism
for updating an appropriate RDS
. resolution is controlled by entities to which assignment
has been delegated
Rules for Lexical Equivalence:
If there are particular algorithms for determining
equivalence between two URN strings in this namespace,
rules can be provided here.
Some examples include:
. mappings between different character set encodings
. equivalence between hyphenated and non-hyphenated
groupings in the identifier string
Conformance with URN Syntax:
This section should outline any special considerations
required for conforming with the URN syntax. This is
particularly applicable in the case of legacy naming
systems that are used in the context of URNs.
For example, if a namespace is used in contexts other
than URNs, it may have a more generous character set than is
immediately available with URNs. This section should flag this
issue and outline necessary mappings to conform to
URN syntax. (E.g., see the section on SICIs in [RFC2288]).
Validation mechanism:
Apart from attempting resolution of a URN, a URN namespace
may provide mechanism for "validating" a URN -- i.e.,
determining whether a given string is currently a
validly-assigned URN. For example, even if an ISBN
URN namespace is created, it is not clear that
all ISBNs will translate directly into "assigned URNs".
A validation mechanims might be:
. uniqueness of identifiers assigned by the namespace's naming
authority
. process of assignment of identfiers in the namespace
. rules for determining lexical equivalence between identifiers in the
namespace
. identification of validation mechanism (to ascertain whether or
not a string is in fact a valid URN in the namespace). This
can include:
. a syntax grammar . a syntax grammar
. an on-line service . an on-line service
. an off-line service . an off-line service
. conformance with RFC1737 requirements (??? these should be
listed out)
The namespace is then identified by the declared owner's private OID (POID) Scope:
and a suffix to distinguish among different namespaces assigned to the
same POID: POID.##
Standardization Process This section should outline the scope of the use of the
identifiers in this namespace. Apart from considerations
of private vs. public namespaces, this section is critical
in evaluating the applicability of a requested NID. For
example, a namespace claiming to deal in "social security
numbers" should have a global scope and address all
social security number structures (unlikely). On the
other hand, at a national level, it is reasonable to
posit a URN namespace for "this nation's social security
numbers".
To establish a standardized URN namespace, the following information 4.0 URN Namespace Registration and NID Assignment
must be described and vetted in an IETF standards-track RFC:
Declared owner of the namespace Different levels of disclosure are expected/defined for namespaces.
Desired NID According to the level of open-forum discussion surrounding
Description of: the disclosure, a URN namespace may be assigned or may request a
particular identifier.
. uniqueness of identifiers assigned by the namespace's naming There are 3 categories of URN namespaces defined here, distinguished
authority by expected level of service and required procedures for registration.
. process of assignment of identfiers in the namespace
. rules for determining lexical equivalence between identifiers in the
namespace
. conformance with RFC1737 requirements (??? these should be
listed out)
. identification of validation mechanism (to ascertain whether or
not a string is in fact a valid URN in the namespace) (??? in
this case, it is required to be one of whois, finger, mail
service)
. match of scope, ownership, and/or global applicability. (?? E.g.,
you can't ask for "social security numbers", but the US
may ask for US social security numbers).
Examples I.. Experimental: These are not registered with IANA. They
take the form
Security Considerations x-<NID>
(??? THere will most assuredly be some!). II. Informal: These are registered with IANA (see Section ??), and
are assigned a number sequence as an identifier.
References III. Formal: These are processed through a full RFC review
process. The NID may be any valid NID string
that does not start with "x-" (see Type I above), and
doesn't clash with an existing, registered NID.
[RFC2168] Ron Daniel & Michael Mealling, "Resolution of Uniform Resource The two-letter country codes are reserved
Identifiers using the Domain Name System", RFC 2168 June 1997. for availability for national registrations.
[RFC2169] Ron Daniel, "A Trivial Convention for using HTTP in URN Resolution", 5.0 Example
RFC 2169, June 1997.
A generic "Internet" namespace has been posited throughout recent
discussions of URNs. This namespace might be defined as follows:
Namespace ID:
"INET" requested.
Declared registrant of the namespace:
T. Cat
leslie@thinkingcat.com
Declaration of structure:
The identifier structure is as follows:
FQDN:<assigned string>
where FQDN is a fully-qualified domain name, and the
assigned string is conformant to URN syntax requirements.
Identifier uniqueness considerations:
Uniqueness is guaranteed as long as the assigned
string is never reassigned for a given FQDN.
Identifier persistence considerations:
Persistence of identifiers is dependent upon suitable
delegation of resolution at the level of "FQDN"s.
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
NAPTR RDS. Within each of these delegated name partitions,
the string may be assigned per local requirements.
e.g. urn:inet:thinkincat.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:
Nothing in particular.
Conformance with URN Syntax:
No special considerations.
Validation mechanism:
None specified.
Scope:
Global.
6.0 Security Considerations
This document largely focuses on providing mechanisms for the
declaration of public information. Nominally, these declarations
should be of relatively low security profile, however there is
always the danger of "spoofing" and providing mis-information.
Information in these declarations should be taken as advisory.
7.0 References
[RFC2168] Ron Daniel & Michael Mealling, "Resolution of Uniform
Resource Identifiers using the Domain Name System", RFC 2168,
June 1997.
[RFC2169] Ron Daniel, "A Trivial Convention for using HTTP in URN
Resolution", RFC 2169, June 1997.
[RFC2288] C. Lynch, C. Preston & R. Daniel, "Using Existing
Bibliographic Identifiers as Uniform Resource Names", RFC 2288,
February 1998.
[RFC2141] Ryan Moats, "URN Syntax", RFC 2141, May 1997. [RFC2141] Ryan Moats, "URN Syntax", RFC 2141, May 1997.
[RFC1737] Karen R Sollins & Larry Masinter, "Functional Requirements for [RFC1737] Karen R Sollins & Larry Masinter, "Functional Requirements
Uniform Resource Names", RFC1737, December 1994 for Uniform Resource Names", RFC1737, December 1994
Authors' Addresses [RFC2276] K. Sollins, "Architectural Principles of Uniform Resource
Name Resolution", RFC 2276, January 1998.
8.0 Authors' Addresses
Leslie L. Daigle Leslie L. Daigle
Bunyip Information Systems Inc Bunyip Information Systems Inc
310 Ste. Catherine St. W 310 Ste. Catherine St. W
Suite 300 Suite 300
Montreal, Quebec, CANADA Montreal, Quebec, CANADA
H2X 2A1 H2X 2A1
voice: +1 514 875-8611 voice: +1 514 875-8611
fax: +1 514 875-8134 fax: +1 514 875-8134
email: leslie@bunyip.com email: leslie@bunyip.com
 End of changes. 41 change blocks. 
112 lines changed or deleted 327 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/