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	wakaba	1.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]