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 |