2004/id/draft-ietf-uri-urn-issues-00.txt



Network Working Group                                     Shirley Browne
Internet-Draft                                               Keith Moore
Expires: 7 January 1996                          University of Tennessee
                                                             7 July 1995


            Issues Concerning URN Assignment and Resolution

                    draft-ietf-uri-urn-issues-00.txt

Status of this Memo

     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 and may be updated, replaced, or obsoleted by other documents at
any time.  It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as "work in progress."

     To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Abstract

     A number of schemes have been proposed over the past year or so for
assigning and resolving Uniform Resource Names (URNs) and for associat-
ing meta-information with URNs.  The Uniform Resource Identifier (URI)
Working Group is currently faced with the task of evaluating these
schemes.  The schemes all claim to satisfy the functional requirements
for URNs stated in RFC 1737.  A number of additional issues that will be
helpful to consider for purposes of evaluation are listed and discussed
in this draft.  Although this draft is long on questions and short on
answers, it attempts to distill the issues on which consensus (even if
it's agreement to disagree) needs to be reached before progress on stan-
dardization can be made.


Browne/Moore             Expires 7 January 1996                 [Page 1]


URN Issues                                                   7 July 1995


Contents


1  Structure and control of the namespace
   1.1  Lifetime of a name
   1.2  Human meaningfulness of names
   1.3  Flat vs. hierarchical
   1.4  Name assignment and ownership
2  Name resolution issues
   2.1  Responsibility for name resolution
   2.2  Efficiency
   2.3  Resolver location
   2.4  Use of existing Domain Name System
3  Meta-information issues
   3.1  What to include and how to structure it
   3.2  Responsibility and write permission
   3.3  Search capabilities
   3.4  Consistency requirements
4  Support for resource replication
   4.1  Consistency requirements
   4.2  Existing mirroring programs
   4.3  Copyright issues
5  Level of standardization
6  Satisfaction of existing naming needs
7  Copyright and licensing issues
8  Author's address


1  Structure and control of the namespace

1.1  Lifetime of a name

     RFC 1737 states that URNs are to be "persistent" identifiers for
resources.  But there are several kinds of persistence:

     One kind of persistence is the lifetime of the binding between a
URN and the resource it describes, independent of whether the resource
can be accessed.  It is generally understood that once a URN is assigned
to a particular resource, that same URN should not be used to refer to a
completely different resource.  If possible, URNs should chosen in such
a way as to ensure global lifetime uniqueness.

     Another kind of persistence is the lifetime of the meaning that a
human will associate with the human-readable portions of a URN.  The
meanings of ordinary words, places, company names, names of countries,
and even trademarks, change over time and due to unforseen circum-
stances.  This affects the persistence of URNs which contain such human-
readable strings.  If URNs are chosen to be somewhat meaningful to


Browne/Moore             Expires 7 January 1996                 [Page 2]


URN Issues                                                   7 July 1995


humans (in addition to being resolvable by machines), the persistence of
the meaning to humans may become an important design consideration.

     Just as the meaning of names changes for humans, the association of
URN naming authorities (whether human readable or not) with their reso-
lution services and/or access locations can also change.  Even if a par-
ticular naming authority is initially well-correlated with particular
resolution or acesss services for URNs using that naming authority, this
correlation may decrease over time.

     Finally, there is the lifetime for which resolution of URNs and
access of the resources named by URNs are available and easily located.

1.2  Human meaningfulness of names

     If names are human meaningful, then humans will have expectations
that may be not be met and thus may lead to confusion and misinforma-
tion.  On the other hand, opaque resource names would prevent humans
from using their intiution to "resolve" them.

1.3  Flat vs. hierarchical

     All the proposed schemes seem to have agreed on at least a two-
level hierarchy for the namespace, consisting of a division by naming
authority, followed by a division by a string assigned by a particular
naming authority.  The flat vs. hierarchical issue has two aspects:

-    the structure used for name assignment

-    the structure used for name resolution

     It would be possible for the namespace to be flat for either pur-
pose but hierarchical for the other.  Arguments have been put forth that
a flat namespace does not scale for either purpose.

     Note that the use of a hierarchy for name resolution does not
require that the hierarchy be either visible in the name or permanently
fixed once names are assigned.

1.4  Name assignment and ownership

     Who will be allowed to assign names - i.e., how easy will it be to
establish oneself as a naming authority?

2  Name resolution issues


Browne/Moore             Expires 7 January 1996                 [Page 3]


URN Issues                                                   7 July 1995


2.1  Responsibility for name resolution

     Should the naming authority that assigns a name be expected to pro-
vide a service that resolves that name, and if so, for how long?  If
only for a limited time, how should the name be resolved after this
limit expires?  Could resolution be handled by third parties in addition
to, or instead of, the service provided by the naming authority?

2.2  Efficiency

     How much, if any, slower than current URL retrieval can URN resolu-
tion be to still be acceptable?  Is the answer for this question differ-
ent for different users and/or different types of resources?

2.3  Resolver location

     Must it be possible to locate a resolver for a name by doing a
lookup based only on the name?  In the case of hierarchical lookup, is
it possible to not expose the resolution hierarchy as part of the name,
so that the lookup hierarchy can change without changing the names?

2.4  Use of existing Domain Name System

     It has been argued that a name resolution system could be more
quickly and reliably implemented by building on top of the existing
Domain Name System, than by building and deploying a new service.

3  Meta-information issues

3.1  What to include and how to structure it

     Should the URI group decide on a minimal set of attributes that are
required to be included in a catalog record for each URN, or should it
defer to outside groups to set such standards?  Note that a number of
standards and conventions already exist -- US MARC, the geospatial meta-
data standard, and the BIDM for software reuse libraries.

     Some meta-information refers to the conceptual properties of a
resource, some to the properties of a specific representation, and some
to the properties of a specific location.  The different categories tend
to have different update frequency, consistency requirements, and write
permissions.  It would thus be desirable to be able to maintain each of
these types of meta-information separately.

3.2  Responsibility and permissions

     Should a naming authority be responsible for supplying meta-
information for names it assigns, or might third parties do a better job


Browne/Moore             Expires 7 January 1996                 [Page 4]


URN Issues                                                   7 July 1995


(e.g., the OCLC Internet cataloging project)?

     If meta-information is maintained under an IETF-sanctioned mecha-
nism, should others besides the originating naming authority be allowed
to contribute meta-information for resources they don't own?

3.3  Search capabilities

     Should a meta information, or URC, service provide search capabili-
ties?  An alternative would be to permit bulk downloading of catalog
records to third parties who could then provide search services, perhaps
for a fee.

3.4  Consistency requirements

     What are the consistency requirements for multiple copies of meta-
information?

4  Support for resource replication

4.1  Consistency requirements

     What are the consistency requirements for multiple locations for a
resource?

4.2  Existing mirroring programs

     How can name-to-location resolution be merged with current mirror-
ing protocols and programs?  In particular, can the "pull model" used by
most existing mirroring programs be supported effectively?

4.3  Copyright issues

     What are the copyright issues involved in mirroring and caching
resources outside the originating authority?

5  Level of standardization

     It is desirable to allow a handful of name resolution schemes to
co-exist initially so as to experimentally evaluate and compare them
under real operating conditions.  Is it possible to do this while pre-
senting a fairly uniform interface to client programs?  If multiple
schemes are permitted to co-exist initially, one or perhaps a few will
eventually win out.  How might names assigned under defunct schemes be
resolved by surviving schemes?


Browne/Moore             Expires 7 January 1996                 [Page 5]


URN Issues                                                   7 July 1995


6  Satisfaction of existing naming needs

     There has been very little in the way of realistic case studies by
the URI Working Group on how URNs will actually be used.  A number of
groups and projects, such as the Computer Science Technical Report
(CSTR) project, the Reuse Library Interoperability Group (RIG), the OCLC
Internet Cataloging Project, the National HPCC Software Exchange (NHSE),
the distributed Problem Solving Environment (PSE) project at Purdue Uni-
versity, and the WebWorks project at Syracuse University, have real nam-
ing needs.  It would be of value to obtain input from these groups on
exactly how the need and plan to use globally unique names, and on what
their performance and other requirements are.

7  Copyright and licensing issues

     Do copyright and licensing issues need to be considered in the con-
text of name resolution?

8  Authors' addresses

Shirley Browne (browne@cs.utk.edu)
Keith Moore (moore@cs.utk.edu)
University of Tennessee
107 Ayres Hall
Knoxville, TN  37996-1301

Tel:  (615) 974-5886
Fax:  (615) 974-8296


Browne/Moore             Expires 7 January 1996                 [Page 6]
1
2
3	Network Working Group Shirley Browne
4	Internet-Draft Keith Moore
5	Expires: 7 January 1996 University of Tennessee
6	7 July 1995
7
8
9	Issues Concerning URN Assignment and Resolution
10
11	draft-ietf-uri-urn-issues-00.txt
12
13	Status of this Memo
14
15	This document is an Internet-Draft. Internet-Drafts are working
16	documents of the Internet Engineering Task Force (IETF), its areas, and
17	its working groups. Note that other groups may also distribute working
18	documents as Internet-Drafts.
19
20	Internet-Drafts are draft documents valid for a maximum of six
21	months and may be updated, replaced, or obsoleted by other documents at
22	any time. It is inappropriate to use Internet-Drafts as reference mate-
23	rial or to cite them other than as "work in progress."
24
25	To learn the current status of any Internet-Draft, please check the
26	"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
27	Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
28	munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
29	ftp.isi.edu (US West Coast).
30
31	Abstract
32
33	A number of schemes have been proposed over the past year or so for
34	assigning and resolving Uniform Resource Names (URNs) and for associat-
35	ing meta-information with URNs. The Uniform Resource Identifier (URI)
36	Working Group is currently faced with the task of evaluating these
37	schemes. The schemes all claim to satisfy the functional requirements
38	for URNs stated in RFC 1737. A number of additional issues that will be
39	helpful to consider for purposes of evaluation are listed and discussed
40	in this draft. Although this draft is long on questions and short on
41	answers, it attempts to distill the issues on which consensus (even if
42	it's agreement to disagree) needs to be reached before progress on stan-
43	dardization can be made.
44
45
46
47
48
49
50
51
52
53
54	Browne/Moore Expires 7 January 1996 [Page 1]
55
56
57
58
59
60
61
62
63	URN Issues 7 July 1995
64
65
66	Contents
67
68
69	1 Structure and control of the namespace
70	1.1 Lifetime of a name
71	1.2 Human meaningfulness of names
72	1.3 Flat vs. hierarchical
73	1.4 Name assignment and ownership
74	2 Name resolution issues
75	2.1 Responsibility for name resolution
76	2.2 Efficiency
77	2.3 Resolver location
78	2.4 Use of existing Domain Name System
79	3 Meta-information issues
80	3.1 What to include and how to structure it
81	3.2 Responsibility and write permission
82	3.3 Search capabilities
83	3.4 Consistency requirements
84	4 Support for resource replication
85	4.1 Consistency requirements
86	4.2 Existing mirroring programs
87	4.3 Copyright issues
88	5 Level of standardization
89	6 Satisfaction of existing naming needs
90	7 Copyright and licensing issues
91	8 Author's address
92
93
94	1 Structure and control of the namespace
95
96	1.1 Lifetime of a name
97
98	RFC 1737 states that URNs are to be "persistent" identifiers for
99	resources. But there are several kinds of persistence:
100
101	One kind of persistence is the lifetime of the binding between a
102	URN and the resource it describes, independent of whether the resource
103	can be accessed. It is generally understood that once a URN is assigned
104	to a particular resource, that same URN should not be used to refer to a
105	completely different resource. If possible, URNs should chosen in such
106	a way as to ensure global lifetime uniqueness.
107
108	Another kind of persistence is the lifetime of the meaning that a
109	human will associate with the human-readable portions of a URN. The
110	meanings of ordinary words, places, company names, names of countries,
111	and even trademarks, change over time and due to unforseen circum-
112	stances. This affects the persistence of URNs which contain such human-
113	readable strings. If URNs are chosen to be somewhat meaningful to
114
115
116
117	Browne/Moore Expires 7 January 1996 [Page 2]
118
119
120
121
122
123
124
125
126	URN Issues 7 July 1995
127
128
129	humans (in addition to being resolvable by machines), the persistence of
130	the meaning to humans may become an important design consideration.
131
132	Just as the meaning of names changes for humans, the association of
133	URN naming authorities (whether human readable or not) with their reso-
134	lution services and/or access locations can also change. Even if a par-
135	ticular naming authority is initially well-correlated with particular
136	resolution or acesss services for URNs using that naming authority, this
137	correlation may decrease over time.
138
139	Finally, there is the lifetime for which resolution of URNs and
140	access of the resources named by URNs are available and easily located.
141
142	1.2 Human meaningfulness of names
143
144	If names are human meaningful, then humans will have expectations
145	that may be not be met and thus may lead to confusion and misinforma-
146	tion. On the other hand, opaque resource names would prevent humans
147	from using their intiution to "resolve" them.
148
149	1.3 Flat vs. hierarchical
150
151	All the proposed schemes seem to have agreed on at least a two-
152	level hierarchy for the namespace, consisting of a division by naming
153	authority, followed by a division by a string assigned by a particular
154	naming authority. The flat vs. hierarchical issue has two aspects:
155
156	- the structure used for name assignment
157
158	- the structure used for name resolution
159
160	It would be possible for the namespace to be flat for either pur-
161	pose but hierarchical for the other. Arguments have been put forth that
162	a flat namespace does not scale for either purpose.
163
164	Note that the use of a hierarchy for name resolution does not
165	require that the hierarchy be either visible in the name or permanently
166	fixed once names are assigned.
167
168	1.4 Name assignment and ownership
169
170	Who will be allowed to assign names - i.e., how easy will it be to
171	establish oneself as a naming authority?
172
173	2 Name resolution issues
174
175
176
177
178
179
180	Browne/Moore Expires 7 January 1996 [Page 3]
181
182
183
184
185
186
187
188
189	URN Issues 7 July 1995
190
191
192	2.1 Responsibility for name resolution
193
194	Should the naming authority that assigns a name be expected to pro-
195	vide a service that resolves that name, and if so, for how long? If
196	only for a limited time, how should the name be resolved after this
197	limit expires? Could resolution be handled by third parties in addition
198	to, or instead of, the service provided by the naming authority?
199
200	2.2 Efficiency
201
202	How much, if any, slower than current URL retrieval can URN resolu-
203	tion be to still be acceptable? Is the answer for this question differ-
204	ent for different users and/or different types of resources?
205
206	2.3 Resolver location
207
208	Must it be possible to locate a resolver for a name by doing a
209	lookup based only on the name? In the case of hierarchical lookup, is
210	it possible to not expose the resolution hierarchy as part of the name,
211	so that the lookup hierarchy can change without changing the names?
212
213	2.4 Use of existing Domain Name System
214
215	It has been argued that a name resolution system could be more
216	quickly and reliably implemented by building on top of the existing
217	Domain Name System, than by building and deploying a new service.
218
219	3 Meta-information issues
220
221	3.1 What to include and how to structure it
222
223	Should the URI group decide on a minimal set of attributes that are
224	required to be included in a catalog record for each URN, or should it
225	defer to outside groups to set such standards? Note that a number of
226	standards and conventions already exist -- US MARC, the geospatial meta-
227	data standard, and the BIDM for software reuse libraries.
228
229	Some meta-information refers to the conceptual properties of a
230	resource, some to the properties of a specific representation, and some
231	to the properties of a specific location. The different categories tend
232	to have different update frequency, consistency requirements, and write
233	permissions. It would thus be desirable to be able to maintain each of
234	these types of meta-information separately.
235
236	3.2 Responsibility and permissions
237
238	Should a naming authority be responsible for supplying meta-
239	information for names it assigns, or might third parties do a better job
240
241
242
243	Browne/Moore Expires 7 January 1996 [Page 4]
244
245
246
247
248
249
250
251
252	URN Issues 7 July 1995
253
254
255	(e.g., the OCLC Internet cataloging project)?
256
257	If meta-information is maintained under an IETF-sanctioned mecha-
258	nism, should others besides the originating naming authority be allowed
259	to contribute meta-information for resources they don't own?
260
261	3.3 Search capabilities
262
263	Should a meta information, or URC, service provide search capabili-
264	ties? An alternative would be to permit bulk downloading of catalog
265	records to third parties who could then provide search services, perhaps
266	for a fee.
267
268	3.4 Consistency requirements
269
270	What are the consistency requirements for multiple copies of meta-
271	information?
272
273	4 Support for resource replication
274
275	4.1 Consistency requirements
276
277	What are the consistency requirements for multiple locations for a
278	resource?
279
280	4.2 Existing mirroring programs
281
282	How can name-to-location resolution be merged with current mirror-
283	ing protocols and programs? In particular, can the "pull model" used by
284	most existing mirroring programs be supported effectively?
285
286	4.3 Copyright issues
287
288	What are the copyright issues involved in mirroring and caching
289	resources outside the originating authority?
290
291	5 Level of standardization
292
293	It is desirable to allow a handful of name resolution schemes to
294	co-exist initially so as to experimentally evaluate and compare them
295	under real operating conditions. Is it possible to do this while pre-
296	senting a fairly uniform interface to client programs? If multiple
297	schemes are permitted to co-exist initially, one or perhaps a few will
298	eventually win out. How might names assigned under defunct schemes be
299	resolved by surviving schemes?
300
301
302
303
304
305
306	Browne/Moore Expires 7 January 1996 [Page 5]
307
308
309
310
311
312
313
314
315	URN Issues 7 July 1995
316
317
318	6 Satisfaction of existing naming needs
319
320	There has been very little in the way of realistic case studies by
321	the URI Working Group on how URNs will actually be used. A number of
322	groups and projects, such as the Computer Science Technical Report
323	(CSTR) project, the Reuse Library Interoperability Group (RIG), the OCLC
324	Internet Cataloging Project, the National HPCC Software Exchange (NHSE),
325	the distributed Problem Solving Environment (PSE) project at Purdue Uni-
326	versity, and the WebWorks project at Syracuse University, have real nam-
327	ing needs. It would be of value to obtain input from these groups on
328	exactly how the need and plan to use globally unique names, and on what
329	their performance and other requirements are.
330
331	7 Copyright and licensing issues
332
333	Do copyright and licensing issues need to be considered in the con-
334	text of name resolution?
335
336	8 Authors' addresses
337
338	Shirley Browne (browne@cs.utk.edu)
339	Keith Moore (moore@cs.utk.edu)
340	University of Tennessee
341	107 Ayres Hall
342	Knoxville, TN 37996-1301
343
344	Tel: (615) 974-5886
345	Fax: (615) 974-8296
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369	Browne/Moore Expires 7 January 1996 [Page 6]