draft-ietf-urn-nid-req-01.txt   draft-ietf-urn-nid-req-02.txt 
INTERNET DRAFT Renato Iannella Internet Draft Leslie L. Daigle
draft-ietf-urn-nid-req-01.txt DSTC Pty Ltd November 19, 1997 Bunyip Information Systems
25 March, 1997 Patrik Faltstrom draft-ietf-urn-nid-req-02.txt Dirk-Willem van Gulik
ISIS/CEO, JRC Ispra
Renato Iannella
DSTC Pty Ltd
Patrik Faltstrom
Tele2/Swipnet Tele2/Swipnet
Namespace Identifier Requirements for URN Services URN Namespace Registration and Standardization Process Mechanisms
Status of this Memo 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 learn the current status of any Internet-Draft, please check To view the entire list of current Internet-Drafts, please check
the `1id-abstracts.txt' listing contained in the Internet- the "1id-abstracts.txt" listing contained in the Internet-Drafts
Drafts Shadow Directories on ftp.is.co.za (Africa), Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Coast), or ftp.isi.edu (US West Coast).
This draft expires 25 September, 1997. Abstract
Abstract: The URN WG has defined a syntax for Uniform Resource Names
========= (URNs) [RFC2141], as well as some proposed mechanisms for their
resolution and use in Internet applications ([RFC2168, RFC2169]).
The whole rests on the concept of individual ''namespaces'' within the
URN structure. Apart from proof-of-concept namespaces, the use
of existing identifiers in URNs has been discussed (??? biblio id
document). This document lays out general definitions of and mechanisms
for establishing URN ''namespaces''.
Services that offer to resolve Uniform Resource Names implicitly Foreword to this Edition
require that they support a persistent and reliable service for an
indeterminate length of time. This draft outlines the requirements for
any such service that wishes to participate as a Namespace Identifier.
Introduction: This document is a very drafty draft. The intention of this version
============= is to lay out the groundwork for some proposed processes. Detail will
be needed. No one has formally approached IANA to set up the registry
this is defining. The model here is not unlike media type registrations.
The Uniform Resource Name (URN) Working Group has defined mechanisms Introduction
for both the syntax [4] and resolution of URNs [1,2]. An framework
for URN discovery systems has also been outlined [3]. This draft
discusses and recommends the requirements for entities that wish
to act as Namespace Identifiers (NIDs) within the URN system.
The URN syntax includes the NID which acts as the scoping For the purposes of URNs, a "namespace" is a collection of uniquely-assigned
indicator for the URN. The NID indicates which Namespace identifiers. A URN namespace itself has an identifier in order to
the URN belongs to and gives hints to the underlying resolution
service.
Consider the following example URNs: . ensure global uniqueness of URNs
. (where desired) provide a cue for the structure of the identifier
urn:znet:metadata.net:dc For example, ISBNs and ISSNs are both collections of identifiers used
urn:buns:555555:annual-report in the traditional publishing world; while there may some number (or numbers)
urn:hoptus:priv:555-ABCD that is both a valid ISBN identifier and ISSN identifier, using different
designators for the two collections ensures that no two URNs will be the same
for different resources.
The NIDs in these cases, "znet", "buns", and "hoptus" all The development of an identifier structure, and thereby a collection
act as top-level namespaces, and hence, must meet certain of identifiers, is a process that is inherently dependent on the needs
guidelines to ensure meeting all the URN requirements [5]. of the identifiers, how they will be assigned, and the uses to which they
In particular: will be put. All of these issues are beyond the scope of the URN
- Global Scope and Uniqueness work.
- Persistence
- Independence
- Resolution
Requirements: This document concerns itself with the mechanical processes of associating
============= an identifier string with a predefined namespace and publication of
identifier structures. Of particular concern are:
Given the four categories above, the requirements for each our . selection of strings to associate with a namespace
now outlined. . 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
Global Scope and Uniqueness. Different levels of disclosure are expected/defined for namespaces.
According to the level of discussion and standardization surrounding the
disclosure, a URN namespace may be assigned or may request a particular
identifier.
- The NID must be registered with IANA to ensure uniqueness and Note that this document restricts itself to the description of processes
demonstrating that it meets the requirements listed in this for the creation of URN namespaces. If "resolution" of any so-created
document. URN identifiers is desired, a separate process of registration in a global
- A simple and limited character set should be imposed to NID directory, such as that provided by the NAPTR [Ref ??] system, is
support global access (as described in [4]). necessary.
- Rules on how the Namespace Specific String are allocated
must be documented.
- Definitions of terms like "equal" and "different" for resources
must be published.
Persistence URN Namespace Categories
- The NID service providers must show that they intend to There are 4 categories of URN namespaces defined here, distinguished by
support the service for an indefinite period of time. expected level of service and required procedures for registration.
- Support facilities must be described and how the service
intends to operate, including "disaster recovery"-like
operations.
- Demonstrated experience in managing an established namespace
system is essential.
- One URN should never be reused for a different resource (where
"different" is defined as in previous paragraph by the namespace).
The URN should be persistent for all times, even though the
resource goes away.
Independence The first three are simple namespace types:
- The NID service providers must also show any relationship I. Experimental: These are not registered with IANA. They take the
(both technical and administrative) that may impede on the form
provision of the URN service. x-<NID>
- However, multi-party participation in the NID service is
an advantage.
Resolution II. Informal: These are registered with IANA (see Section ??), and
are assigned a number based on a private OID ("POID"
namespaces).
- The NID service providers must produce an RFC III. Standardized: These are processed through a full standards-track
describing the technical characteristics of the URN RFC review process. The NID may be any valid NID string
resolution service, including security considerations. that does not clash with an existing, registered NID.
- The NID service providers may elect not to have the
resolution service publically available.
Example: The fourth is a composite namespace type (i.e., one constructed for
======= the express purpose of later subdivision):
(1) urn:buns:555555:annual-report IV. Top-level: These are processed through a full standards-track
RFC review process. The result is not a NID so much
as a top-level NID structure, which will be subdivided by the
rules laid out in the top-level NID RFC. These NID
strings must not clash with existing, registered NIDs;
additionally, the RFC1766 country code strings are
reserved for use by countries that desire to so-obtain
a top-level NID.
This URN, in the namespace called "buns" is referring to the Registration Procedures
document named annual-report, in postscript format.
At a later stage, that resource is replaced by a text version, which To register a namespace (for type II namespaces, informal), the following
lacks the pictures, but that is ok, because the namespace has decided information must be provided to the IANA:
that postscript format documents and text documents are considered the
same even though the figures doesn't exist in the textual version.
In the third stage, the report is removed, and replaced with a report Declared owner of the namespace
for a different year. This new report gets a new URN because it is Description of:
considered being a different document.
The old URN is never reused. . 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
. an on-line service
. an off-line service
. conformance with RFC1737 requirements (??? these should be
listed out)
(2) urn:foo:bar:current-weather The namespace is then identified by the declared owner's private OID (POID)
urn:foo:bar:weather/19970325 and a suffix to distinguish among different namespaces assigned to the
same POID: POID.##
These are two URNs referring at one stage to the same resource, i.e. Standardization Process
on the 25th of March 1997. On the 26th of March 1997,
urn:foo:bar:current-weather is referring to the same resource as
urn:foo:bar:weather/19970326.
Conclusion: To establish a standardized URN namespace, the following information
=========== must be described and vetted in an IETF standards-track RFC:
This draft has outlined the requirements for providers of Declared owner of the namespace
NID services for URN systems. The objective is to maintain Desired NID
a high persistence rate for URN services, and these requirements Description of:
are aimed at ensuring a high level of service stability.
References: . 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
. 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).
[1] Ron Daniel & Michael Mealling, "Resolution of Uniform Resource Examples
Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt,
February, 1997.
[2] Ron Daniel, "A Trivial Convention for using HTTP in URN Resolution", Security Considerations
draft-ietf-urn-http-conv-01.txt, February 1997
[3] Karen R Sollins, "Requirements and a Framework for URN Resolution (??? THere will most assuredly be some!).
Systems", draft-ietf-urn-req-frame-00.txt, November 1996
[4] Ryan Moats, "URN Syntax", draft-ietf-urn-syntax-02, January 1997. References
[5] Karen R Sollins & Larry Masinter, "Functional Requirements for [RFC2168] Ron Daniel & Michael Mealling, "Resolution of Uniform Resource
Uniform Resource Names", RFC1737, December 1994 Identifiers using the Domain Name System", RFC 2168 June 1997.
Security Considerations [RFC2169] Ron Daniel, "A Trivial Convention for using HTTP in URN Resolution",
======================= RFC 2169, June 1997.
It is a requirement that it in the definitions of a namespace are [RFC2141] Ryan Moats, "URN Syntax", RFC 2141, May 1997.
included sections on security covering for example:
+ Spoofing of servers [RFC1737] Karen R Sollins & Larry Masinter, "Functional Requirements for
+ Verification of responses Uniform Resource Names", RFC1737, December 1994
Because a namespace can decide that a resolution service is not Authors' Addresses
publically available, it is possible to use firewall installations and
other traffic limiting constructions to diconnect the namespace from
the global Internet.
Author Contact Information: Leslie L. Daigle
=========================== Bunyip Information Systems Inc
310 Ste. Catherine St. W
Suite 300
Montreal, Quebec, CANADA
H2X 2A1
voice: +1 514 875-8611
fax: +1 514 875-8134
email: leslie@bunyip.com
Dirk-Willem van Gulik
ISIS/STA/CEO - TP 270
Joint Research Centre Ispra
21020 Ispra (Va)
Italy.
voice: +39 332 78 9549 or 5044
fax: +39 332 78 9185
email: Dirk.vanGulik@jrc.it
Renato Iannella Renato Iannella
DSTC Pty Ltd DSTC Pty Ltd
Gehrmann Labs, The Uni of Queensland Gehrmann Labs, The Uni of Queensland
AUSTRALIA, 4072 AUSTRALIA, 4072
voice: +61 7 3365 4310 voice: +61 7 3365 4310
fax: +61 7 3365 4311 fax: +61 7 3365 4311
email: renato@dstc.edu.au email: renato@dstc.edu.au
Patrik Faltstrom Patrik Faltstrom
 End of changes. 45 change blocks. 
129 lines changed or deleted 155 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/