2004/id/draft-ietf-uri-resource-names-02.txt


INTERNET--DRAFT                                         Chris Weider
IETF URI Working Group                                  Bunyip Information
                                                          Systems, Inc.
                                                        Peter Deutsch
                                                        Bunyip Information
                                                          Systems, Inc.
                                                        July, 1994

                Uniform Resource Names
          <draft-ietf-uri-resource-names-02.txt>

Status of this Memo

In this paper, the authors propose an identifier, called 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 January 28, 1995.


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.


INTERNET--DRAFT         Uniform Resource Names                  Weider, Deutsch

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 1994]. 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. 

3.2 What URNs are *not*

URNs are not required 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 five 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 four components to the URN, separated by colons; the keyword
'URN', a naming authority scheme identifier, a naming authority identifier, and an 
opaque string. Each part is described below. 

3.3.1 URN examples

<URN:IANA:merit.edu:1929642>

<URN:ISBN:0_201_12:xyzxmnopq>

<URN:IANA:12456:1.34.2345>


INTERNET--DRAFT         Uniform Resource Names                  Weider, Deutsch

3.3.2 The naming authority scheme identifier

The naming authority scheme identifier is a string which is the name of a 
protocol or organization which guarantees the uniqueness of the naming 
authority identifier which follows. Naming authority scheme identifiers defined 
at this time are 

        IANA
        ISBN
        ISSN

3.3.4 The naming authority identifier

This string, along with the naming authority scheme identifier, identifies a 
naming authority that may assign URNs to resources. This string may have 
internal syntax depending on the naming authority scheme identifier associated 
with it; for example, the naming authority identifier space associated with IANA 
may be hierarchical and multi-leveled.

3.3.5 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 constraints of the 
allowed character set.

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 must be case-insensitive.

        2: A given opaque string, once assigned, must 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 1994]). 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.

Several of these requirements are specified by the URN Requirements Document
[Sollins 1994] and must be adhered to.

INTERNET--DRAFT         Uniform Resource Names                  Weider, Deutsch

        
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
                ISSN

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 unless they are escaped with the '\' character. 
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.


urn              <URN: Authority_Id : opaque_string >

Authority_Id            Scheme_ID  : [Individual ]
Scheme_ID               IANA | ISBN | ISSN
Individual              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.

[Sollins 1994]  Sollins, K, and Masinter, L. Requirements for Uniform Resource
              Names, Internet Draft, June, 1994. Available as

ftp://nic.merit.edu/documents/internet-drafts/draft-sollins-urn-01.txt

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

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

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


INTERNET--DRAFT         Uniform Resource Names                  Weider, Deutsch


7: Author's addresses

Chris Weider
clw@bunyip.com
Bunyip Information Systems, Inc.
2001 S. Huron Parkway #12
Ann Arbor, MI 48104
Phone: +1 (313) 971-2223
Fax: +1 (313) 971-2223

Peter Deutsch
peterd@bunyip.com
Bunyip Information Systems, Inc.
310 St-Catherine St West
suite 202,
Montreal, Quebec H2X 2A1
CANADA
1	wakaba	1.1
2			INTERNET--DRAFT Chris Weider
3			IETF URI Working Group Bunyip Information
4			Systems, Inc.
5			Peter Deutsch
6			Bunyip Information
7			Systems, Inc.
8			July, 1994
9
10			Uniform Resource Names
11			<draft-ietf-uri-resource-names-02.txt>
12
13			Status of this Memo
14
15			In this paper, the authors propose an identifier, called the Uniform Resource
16			Name (URN), which is designed to provide persistent naming for resources
17			and objects on the Internet.
18
19			This document is an Internet Draft. Internet Drafts are working
20			documents of the Internet Engineering Task Force (IETF), its Areas,
21			and its Working Groups. Note that other groups may also distribute
22			working documents as Internet Drafts.
23
24			Internet Drafts are draft documents valid for a maximum of six
25			months. Internet Drafts may be updated, replaced, or obsoleted
26			by other documents at any time. It is not appropriate to use
27			Internet Drafts as reference material or to cite them other than
28			as a "working draft" or "work in progress."
29
30			Please check the I-D abstract listing contained in each Internet
31			Draft directory to learn the current status of this or any
32			other Internet Draft.
33
34			This Internet Draft expires January 28, 1995.
35
36
37			1: Introduction
38
39			A Uniform Resource Name (URN) is an identifier which can be used to uniquely
40			identify a resource, and is designed to provide persistent naming for
41			networked objects. This name would stay the same no matter what the
42			current location(s) of the object was.
43
44			2: Motivation
45
46			This work comes out of the discussions held at the Uniform Resource Identifier
47			meetings at the IETF, and from further discussions among interested parties.
48			Currently, the only standard identification scheme for resources on the Net is
49			the Uniform Resource Locator (URL) [Berners-Lee 1993]. This "Locator"
50			is designed to provide a uniform way of specifying location and retrieval
51			information for networked objects. The URL, however, will not provide a stable,
52			long-lived reference to a resource as the resources have a bad habit of moving
53			out from under the locator. Also, a given resource may have multiple URLs if
54			it resides at a number of different locations on the net, or is available
55			under a number of different access methods. Thus it is difficult to tell,
56			given two different URLs, whether the resources they point to are the same
57			or different without retrieving both of them. The Uniform Resource Name, or
58			URN, has been designed to alleviate these problems.
59
60
61			INTERNET--DRAFT Uniform Resource Names Weider, Deutsch
62
63			3: The Uniform Resource Name (URN)
64
65			3.1 Functionality
66
67			The URN is designed to provide persistent naming for objects on the net. It
68			is intended to be used in conjunction with a directory service, which can
69			provide a URN -> URL mapping [Weider 1994]. This URN-URL architecture allows
70			permanent references to be made to resources without worrying about their
71			current locations. It is also intended to provide some detection of duplicates
72			in responses to queries of various resource location services.
73
74			3.2 What URNs are not
75
76			URNs are not required to be human-readable in the sense that a human could
77			look at the URN and determine anything about the contents of the resource.
78			While the Naming Authority (q.v.) has the final determination of the contents
79			(subject to the syntax constraints), the Naming Authority is STRONGLY
80			discouraged from placing metainformation about the resource into the resource's
81			URN, as the URNs are not expected to be read, and because this paper will
82			specify only five consistent components of the URN. Although there have been a
83			number of proposals placing extensive semantics on the contents of the URN
84			[Spero 1992, Kunze 1993], it was decided by the authors of all the proposals
85			that all metainformation should be conveyed using another mechanism, and that
86			the Naming Authority should assume that humans will never look at the contents
87			of the URN to determine qualities of the resource they are retrieving, and
88			would not be required to guess from a given URN the URN of a document which
89			might be related.
90
91			3.3 Components of the URN
92
93			There are four components to the URN, separated by colons; the keyword
94			'URN', a naming authority scheme identifier, a naming authority identifier, and an
95			opaque string. Each part is described below.
96
97			3.3.1 URN examples
98
99			<URN:IANA:merit.edu:1929642>
100
101			<URN:ISBN:0_201_12:xyzxmnopq>
102
103			<URN:IANA:12456:1.34.2345>
104
105
106
107			INTERNET--DRAFT Uniform Resource Names Weider, Deutsch
108
109			3.3.2 The naming authority scheme identifier
110
111			The naming authority scheme identifier is a string which is the name of a
112			protocol or organization which guarantees the uniqueness of the naming
113			authority identifier which follows. Naming authority scheme identifiers defined
114			at this time are
115
116			IANA
117			ISBN
118			ISSN
119
120			3.3.4 The naming authority identifier
121
122			This string, along with the naming authority scheme identifier, identifies a
123			naming authority that may assign URNs to resources. This string may have
124			internal syntax depending on the naming authority scheme identifier associated
125			with it; for example, the naming authority identifier space associated with IANA
126			may be hierarchical and multi-leveled.
127
128			3.3.5 The Opaque String
129
130			The opaque string component of the URN is any string the Naming Authority
131			wishes to assign to a given resource, subject only to the constraints of the
132			allowed character set.
133
134			As mentioned above, the Naming Authority should not assume that a
135			human will ever read the URN. Also, the Naming Authority, in assigning an
136			opaque string to a given resource, should keep the following guidelines in
137			mind:
138
139			1: A given opaque string must be case-insensitive.
140
141			2: A given opaque string, once assigned, must never be reused. These
142			are expected to be persistent names for resources (think in terms
143			of decades).
144
145			3: In assigning an opaque string, and thus creating a URN, the Naming
146			Authority should make provisions for a URN -> URL mapping
147			function. This need be nothing more than finding an organization
148			which is already providing this service for other URNs and making
149			arrangements to have them translate for the new URN, or could
150			be as involved as creating a new software agent to provide this
151			service. Remember that a name is no good without some way of
152			getting a location.
153
154			4: URNs will be returned as pointers from a resource location service.
155			(See [Weider 1994]). Consequently, a Naming Authority should give
156			some thought to the assignation of new URNs for resources which
157			are derived in some fashion from other resources to which that
158			Authority has already assigned URNs. For example, should the
159			Postscript version and the ASCII version of a paper have the
160			same URN? While there are no universally applicable answers to
161			questions like these (for example, should the Russian and English
162			versions of a scientific paper have the same URN?) an Authority
163			should keep in mind that users will want to weed out duplicate
164			resources in the lists of URNs returned by a resource location
165			service, and consequently will be doing a lot of equality testing
166			on the URNs.
167
168			Several of these requirements are specified by the URN Requirements Document
169			[Sollins 1994] and must be adhered to.
170
171			INTERNET--DRAFT Uniform Resource Names Weider, Deutsch
172
173
174			4: Setting up as a Naming Authority
175
176			There are 2 scheme identifiers listed here; others will no doubt be suggested
177			and added as this draft circulates. They are:
178
179			IANA
180			ISBN
181			ISSN
182
183			To set one's organization up as a Naming Authority, one can use the ISBN
184			publisher ID one has been assigned, or one can apply for an Enterprise
185			Number from the IANA (Internet Assigned Number Authority) if the organization
186			does not already have one. The general syntax is listed in section 5.
187
188			5: Syntax
189
190			Below is a BNF like description of the syntax of the URN. Spaces have
191			been used here to separate components for readability, spaces are NOT ALLOWED
192			in a syntactically correct URN unless they are escaped with the '\' character.
193			Square brackets '[' and ']' are used to indicate optional parts;
194			a vertical line "\|" indicates alternatives. Single letters and digits stand
195			for themselves. All words of more than one letter are either expanded further
196			in the syntax or represent themselves.
197
198
199			urn <URN: Authority_Id : opaque_string >
200
201			Authority_Id Scheme_ID : [Individual ]
202			Scheme_ID IANA \| ISBN \| ISSN
203			Individual xalphas
204			xalphas xalpha [ xalphas ]
205			xalpha a \| b \| c \| d \| e \| f \| g \| h \| i \| j \| k \| l \|
206			m \| n \| o \| p \| q \| r \| s \| t \| u \| v \| w \| x \|
207			y \| z \| A \| B \| C \| D \| E \| F \| G \| H \| I \| J \|
208			K \| L \| M \| N \| O \| P \| Q \| R \| S \| T \| U \| V \|
209			W \| X \| Y \| Z \| 1 \| 2 \| 3 \| 4 \| 5 \| 6 \| 7 \| 8 \|
210			9 \| 0 \| - \| _ \| . \| @
211
212
213			6: References
214
215			[Kunze 1993] Kunze, John, Resource Citations for Electronic Discovery and
216			Retrieval, March, 1993. Circulated to ietf-uri mailing list.
217
218			[Sollins 1994] Sollins, K, and Masinter, L. Requirements for Uniform Resource
219			Names, Internet Draft, June, 1994. Available as
220
221			ftp://nic.merit.edu/documents/internet-drafts/draft-sollins-urn-01.txt
222
223			[Spero 1992] Spero, Simon, Uniform Resource Numbers, November 1992.
224			Circulated to ietf-uri mailing list.
225
226			[Weider 1994] Weider, Chris and Deutsch, Peter. A Vision of an Integrated
227			Internet Information Service, July, 1994. Available as
228
229			ftp://nic.merit.edu/documents/internet-drafts/draft-ietf-iiir-vision-01.txt
230
231
232
233			INTERNET--DRAFT Uniform Resource Names Weider, Deutsch
234
235
236			7: Author's addresses
237
238			Chris Weider
239			clw@bunyip.com
240			Bunyip Information Systems, Inc.
241			2001 S. Huron Parkway #12
242			Ann Arbor, MI 48104
243			Phone: +1 (313) 971-2223
244			Fax: +1 (313) 971-2223
245
246			Peter Deutsch
247			peterd@bunyip.com
248			Bunyip Information Systems, Inc.
249			310 St-Catherine St West
250			suite 202,
251			Montreal, Quebec H2X 2A1
252			CANADA