Internet Draft on URNs

[Chris Weider <[e-mail]>]

Gang:
   This is the URN draft that Peter and I put together (but unfortunately
did not get distributed) before the Columbus IETF. At that IETF, it was
decided that since our proposal looked so much like the URN we all decided
on that we would make minor mods to our paper and submit it. So here it is!
As always, comments are greatly appreciated. Please note that we have
gotten 'round the recent 'whitespace' controversy by disallowing it in the
URN.... any white space in a presented URN can safely be ignored :^).
Chris Weider


INTERNET--DRAFT						Chris Weider
IETF URI Working Group					Merit Network, Inc.
							Peter Deutsch
							Bunyip Information
							  Systems, Inc.
							May, 1993

		Uniform Resource Names

Status of this Memo

In this paper, the authors propose an identifier, call the Uniform Resource
Name (URN), which is designed to provide persistent naming for resources
and objects on the Internet.

        This document is an Internet Draft.  Internet Drafts are working
        documents of the Internet Engineering Task Force (IETF), its Areas,
        and its Working Groups.  Note that other groups may also distribute
        working documents as Internet Drafts.

        Internet Drafts are draft documents valid for a maximum of six
        months. Internet Drafts may be updated, replaced, or obsoleted
        by other documents at any time. It is not appropriate to use 
        Internet Drafts as reference material or to cite them other than
        as a "working draft" or "work in progress."

        Please check the I-D abstract listing contained in each Internet
        Draft directory to learn the current status of this or any 
        other Internet Draft.

	This Internet Draft expires November 10, 1993.


1: Introduction

A Uniform Resource Name (URN) is an identifier which can be used to uniquely
identify a resource, and is designed to provide persistent naming for 
networked objects.  This name would stay the same no matter what the 
current location(s) of the object was.

2: Motivation

This work comes out of the discussions held at the Uniform Resource Identifier
meetings at the IETF, and from further discussions among interested parties.
Currently, the only standard identification scheme for resources on the Net is
the Uniform Resource Locator (URL) [Berners-Lee 1993]. This "Locator"
is designed to provide a uniform way of specifying location and retrieval 
information for networked objects. The URL, however, will not provide a stable,
long-lived reference to a resource as the resources have a bad habit of moving 
out from under the locator. Also, a given resource may have multiple URLs if
it resides at a number of different locations on the net, or is available
under a number of different access methods. Thus it is difficult to tell,
given two different URLs, whether the resources they point to are the same
or different without retrieving both of them. The Uniform Resource Name, or 
URN, has been designed to alleviate these problems.

3: The Uniform Resource Name (URN)

3.1 Functionality

The URN is designed to provide persistent naming for objects on the net. It
is intended to be used in conjunction with a directory service, which can 
provide a URN -> URL mapping [Weider 1993]. This URN-URL architecture allows 
permanent references to be made to resources without worrying about their 
current locations. It is also intended to provide some detection of duplicates 
in responses to queries of various resource location services. 

INTERNET--DRAFT		  Uniform Resource Names	        Weider, Deutsch


3.2 What URNs are *not*

URNs are not intended to be human-readable in the sense that a human could
look at the URN and determine anything about the contents of the resource.
While the Naming Authority (q.v.) has the final determination of the contents
(subject to the syntax constraints), the Naming Authority is STRONGLY
discouraged from placing metainformation about the resource into the resource's
URN, as the URNs are not expected to be read, and because this paper will
specify only four consistent components of the URN. Although there have been a 
number of proposals placing extensive semantics on the contents of the URN 
[Spero 1992, Kunze 1993], it was decided by the authors of all the proposals
that all metainformation should be conveyed using another mechanism, and that 
the Naming Authority should assume that humans will never look at the contents 
of the URN to determine qualities of the resource they are retrieving, and 
would not be required to guess from a given URN the URN of a document which 
might be related.

3.3 Components of the URN

There are three components to the URN; a wrapper, a Naming Authority identifier,
and an opaque 'name'. The general syntax is:


	URN:Naming_Authority_identifier::opaque_string:::

         ^  |                          ^             | ^
         |_________________ wrapper ___|_______________|

Blanks, <crlf>s, and non-printing characters are NOT allowed. For a full
allowable character set, see section 5.

3.3.1 The wrapper

The wrapper consists of the 4 character header 'URN:', two consecutive
colons to separate the Naming_Authority_Identifier component from the 
opaque_string component, and the 3 character trailer ':::'.

3.3.2 The Naming Authority Identifier

The Naming Authority identifier consists of two sub-components, a 'scheme
identifier' and an 'individual identifier'. A scheme identifier is the
name of a protocol or organization which can guarantee the uniqueness and
resolvability of the individual identifier. The individual identifier is
the identifier of an organization which has assigned the opaque string 
component to the resource and can resolve the URN to a set of URLs for the
resource. The scheme identifier and the individual identifier are separated by
a colon. For example, typical Naming Authorities might be 

   	IANA:42117

or

 	ISBN_Publisher_ID:0_201_12
etc.

3.3.3 The Opaque String

The opaque string component of the URN is any string the Naming Authority 
wishes to assign to a given resource, subject only to the syntax description


INTERNET--DRAFT           Uniform Resource Names                Weider, Deutsch


below. As mentioned above, the Naming Authority should not assume that a 
human will ever read the URN. Also, the Naming Authority, in assigning an
opaque string to a given resource, should keep the following guidelines in 
mind:

  	1: A given opaque string should be case-insensitive (for compatibility
	   with very old systems).

	2: A given opaque string, once assigned, should never be reused. These
	   are expected to be persistent names for resources (think in terms
	   of decades).

	3: In assigning an opaque string, and thus creating a URN, the Naming
	   Authority should make provisions for a URN -> URL mapping
	   function. This need be nothing more than finding an organization
	   which is already providing this service for other URNs and making
	   arrangements to have them translate for the new URN, or could
	   be as involved as creating a new software agent to provide this
	   service.  Remember that a name is no good without some way of 
	   getting a location.

	4: URNs will be returned as pointers from a resource location service.
	   (See [Weider 1993]). Consequently, a Naming Authority should give
	   some thought to the assignation of new URNs for resources which
	   are derived in some fashion from other resources to which that
	   Authority has already assigned URNs. For example, should the
	   Postscript version and the ASCII version of a paper have the
	   same URN? While there are no universally applicable answers to
	   questions like these (for example, should the Russian and English
	   versions of a scientific paper have the same URN?) an Authority
	   should keep in mind that users will want to weed out duplicate
	   resources in the lists of URNs returned by a resource location
	   service, and consequently will be doing a lot of equality testing
	   on the URNs.

	
4: Setting up as a Naming Authority

There are 2 scheme identifiers listed here; others will no doubt be suggested
and added as this draft circulates. They are:

		IANA
		ISBN_Publisher_ID

To set one's organization up as a Naming Authority, one can use the ISBN 
publisher ID one has been assigned, or one can apply for an Enterprise
Number from the IANA (Internet Assigned Number Authority) if the organization
does not already have one. The general syntax is listed in section 5.

5: Syntax

Below is a BNF like description of the syntax of the URN. Spaces have 
been used here to separate components for readability, spaces are NOT ALLOWED
in a syntactically correct URN. Square brackets '[' and ']' are used to
indicate optional parts; a vertical line "|" indicates alternatives.
Single letters and digits stand for themselves. All words of more than one
letter are either expanded further in the syntax or represent themselves.


INTERNET--DRAFT           Uniform Resource Names                Weider, Deutsch


urn			URN: Authority_Id :: opaque_string :::
Authority_Id		Scheme_ID [ : Individual ]
Scheme_ID		IANA | ISBN_Publisher_ID
Individual		xalphas
opaque_string		xalphas
xalphas			xalpha [ xalphas ]
xalpha			a | b | c | d | e | f | g | h | i | j | k | l |
			m | n | o | p | q | r | s | t | u | v | w | x |
			y | z | A | B | C | D | E | F | G | H | I | J |
			K | L | M | N | O | P | Q | R | S | T | U | V |
			W | X | Y | Z | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
			9 | 0 | - | _ | . | @

6: References

[Kunze 1993]  Kunze, John, Resource Citations for Electronic Discovery and 
	      Retrieval, March, 1993. Circulated to ietf-uri mailing list.

[Spero 1992]  Spero, Simon, Uniform Resource Numbers, November 1992. 
	      Circulated to ietf-uri mailing list.

[Weider 1993] Weider, Chris and Deutsch, Peter. A Vision of an Integrated 
	      Internet Information Service, March, 1993. Available as

ftp://nic.merit.edu/documents/internet-drafts/draft-ietf-iiir-vision-00.txt

7: Author's addresses

Chris Weider
[e-mail]
Merit Network, Inc.
2901 Hubbard, Pod G
Ann Arbor, MI 48109
Phone: [phone]
Fax: [phone]

Peter Deutsch
[e-mail]
Bunyip Information Systems
310 St-Catherine St West
suite 202,
Montreal, Quebec H2X 2A1
CANADA