2004/id/draft-ietf-uri-urn-res-descript-00.txt

IETF URI Working Group                                         Paul E. Hoffman
Internet-Draft                                               Proper Publishing
draft-ietf-uri-urn-res-descrip-00                              Ron Daniel, Jr.
Expires October 21, 1995                        Los Alamos National Laboratory


                           URN Resolution Overview

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.
Internet-Drafts may be updated, replaced, or obsoleted by other documents
at any time. It s not appropriate to use Internet- Drafts as reference
material or to cite them other than as a "working draft" or "work in
progress."

To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained n the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu or
munnari.oz.au.

Abstract

This document gives an overview of how Uniform Resource Names (URNs) will
be resolved. It describes how different URN resolution schemes will fit
together, the requirements for the multiple URN schemes, expectations for
URN clients, and other general resolution issues.

This document does not cover any specific resolution schemes, the syntax
for URNs, or the format of resolution results. It is expected that these
issues (and other URN-related topics) will be covered in different Internet
Drafts submitted to the IETF URI Working Group.

1. Introduction

A URN (Uniform Resource Name) is the name of a resource within the context
of a larger Internet information architecture known as Uniform Resource
Identification. URNs are simple text strings that unambiguously identify an
Internet resource. Any Internet resource may have multiple names, but all
uses of a particular name identify the same resources, as viewed by their
publisher.

Using a URN resolution service, an Internet user or program can retrieve
information about the named resource. The minimum set of requirements for
URNs are described in [URNR].

Resolving a URN returns information about that named resource, such as a
description of the resource, the location or locations of the resource, and
bibliographic information about the resource. URNs differ from URLs
(Uniform Resource Locators) described in RFC 1738 [URL] in that URNs allow
resources on the Internet to be specified by name instead of by location.
URNs return information about the resource, not the resource itself.

Using URNs has many advantages for identifying resources, including:

- The information in a resource may move in the future. For example, as
some Internet services get too popular for their original hosts, they move
to different systems which have different URLs. Also, a service might move
from host system to host system with the person who maintains it.

- Users can easily access metainformation about a resource without
accessing the resource itself. A user might want to see the bibliographic
information about a resource without getting the resource, particularly if
it costs money to get the resource. Other useful metainformation that a
user might want to see before accessing a resource includes the name of the
maintainer of the resource, the language in which the resource is in, the
price of the resource, the requirements of the user before reading the
resource, and so on.

- A resource may exist in many locations on the Internet. By resolving a
single URN, the user can get a list of URLs from which to access the
resource and more complete bibliographic information from a URC [URC]. This
list can include valuable metainformation such as suggestions about the
best location for the user to retrieve the resource from based on cost,
speed, or other factors.

It is important to understand that URNs are neither a superset or a subset
of URLs: they are different. The difference between URNs and URLs is
similar to that between the title of a book and a locator for it on the
shelf.

2. Syntax

The syntax for URNs is described in [URNS]. This general syntax has
provision for multiple, specific URN schemes.

3. URN Resolution Schemes

There are many methods for resolving URNs. Each method is called a
"scheme". A URN resolution scheme defines the following:
- the name of the scheme, described in [URNS]
- the syntax for the scheme-specific part of the URN
- the transport protocol or protocols used to resolve URN with that scheme
- the types of resolution results that the scheme might return

Having more than one URN resolution scheme allows URNs to be used for such
naming schemes as ISBNs (International Standard Book Numbering system),
ISSNs (International Standard Serial Numbering system), and other naming
schemes that are not currently on the Internet. It also allows for naming
schemes that can be resolved in ways that are distributed and not
location-specific.

Each scheme is defined in its own Internet Draft. These drafts must include
all the above information, as well as how the scheme meets the requirements
in [URNR].

4. Overview of URN Resolution

URN resolution can be described in two parts: the resolution request and
the resolution result. A resolution request describes the URN to be
resolved to the resolution server. A resolution result is the text that is
returned from the resolution server; it gives the requested information
about the resource named in the URN.

4.1 Resolution Requests

A URN is resolved by communicating with a URN resolution service. At a
minimum, all URN resolution services provide a request/response system: a
single URN is specified, and a single response is returned. The service can
be stateless or can preserve state, depending on the communication protocol
used. Each resolution request must give enough information to the
resolution server that it can completely and unambiguously identify which
URN is being specified. More capable URN resolvers may accept queries which
select sets of URNs, but their operation is outside the scope of this
draft.

The current query-response system for resolving URNs is quite simple.
Future extensions to this system will accommodate more capable query
languages.

4.2 Resolution Results

The resolution request specifies the information desired in the response.
This might be simple list of URLs, or a more informative reply with a great
deal of additional information. If possible, the request should be able to
indicate the desired format for the response, such as plain text, HTML, or
some application specific binary encoding suitable for cryptographic
operations.

The resolution server returns the results of each resolution request in a
single response.

If the resolution request specifies desired formats for the response, the
resolution server should attempt to return only those types of results.
However, it is acknowledged that this may be impractical or impossible for
some resolution servers, and the client should be able to handle (or at
least ignore) resolution results that are not of a requested type.

5. URN Resolution Clients, Proxies, and Caching

URN clients are allowed to interpret the resolution result and present the
user with a better interface than just the text that is returned. For
example, an intelligent Gopher-based URN client resolving an HTTP-based URN
could go through a Gopher-to-HTTP gateway can select the URLs with the
"gopher:" scheme and create a Gopher menu of them. Similarly, an
intelligent HTML-based URN client can reformat a resolution result as HTML
text with the URLs as links that can be selected.

In order to make URN resolution available to as many Internet users as
possible, it is assumed that resolution may take place through protocol
proxies and gateways. Proxies and gateways allow Internet users who do not
have URN clients, or whose clients do not speak in all the transport
protocols described in the various URN schemes, to resolve URNs. Current
proxies and gateways should work well for this purpose, but they should be
enhanced and more widely available. Some sites will choose to have local
proxies and gateways, while other sites will allow people from outside
their site to use their proxies and gateways freely.

URN resolution clients, proxies, and gateways may choose to cache
resolution results in order to speed resolution and to reduce Internet
traffic. Caching should only be performed using the native mechanisms in
the transport protocols to assure that URNs whose response content changes
rapidly are not accidentally cached.

6. Security Implications

Attempting to resolve a URN can cause unencoded messages to be sent between
two systems on the Internet, and thus can introduce many security concerns.
Resolution requests and responses can be logged at the originating site,
the recipient site, and intermediary sites along the delivery path. If
secure encryption is not used, resolution requests and responses can also
be read at any of those sites.

All the security implications of each transport protocol are probably the
same for URNs transported using those protocols.

7. References

[URC] Internet-Draft, "URC Scenarios and Requirements". The name of the
draft at the time of this writing is "draft-ietf-uri-urc-req-01".

[URL] RFC 1738, "Uniform Resource Locators (URL)".

[URNR] RFC 1737, "Functional Requirements for Uniform Resource Names".

[URNS] Internet-Draft, "Generic URN Syntax". The name of the draft at the
time of this writing is "draft-ietf-uri-urn-syntax-00".

8. Author Contact Information

Paul E. Hoffman
Proper Publishing
127 Segre Place
Santa Cruz, CA, USA  95060
voice:  (408) 426-6222
phoffman@proper.com

Ron Daniel Jr.
MS B287
Los Alamos National Laboratory
Los Alamos, NM, USA 87545
voice:  (505) 665-0597
fax:  (505) 665-4939
rdaniel@lanl.gov


1	IETF URI Working Group Paul E. Hoffman
2	Internet-Draft Proper Publishing
3	draft-ietf-uri-urn-res-descrip-00 Ron Daniel, Jr.
4	Expires October 21, 1995 Los Alamos National Laboratory
5
6
7	URN Resolution Overview
8
9	Status of this memo
10
11	This document is an Internet-Draft. Internet-Drafts are working documents
12	of the Internet Engineering Task Force (IETF), its areas, and its working
13	groups. Note that other groups may also distribute working documents as
14	Internet-Drafts.
15
16	Internet-Drafts are draft documents valid for a maximum of six months.
17	Internet-Drafts may be updated, replaced, or obsoleted by other documents
18	at any time. It s not appropriate to use Internet- Drafts as reference
19	material or to cite them other than as a "working draft" or "work in
20	progress."
21
22	To learn the current status of any Internet-Draft, please check the
23	1id-abstracts.txt listing contained n the Internet-Drafts Shadow
24	Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu or
25	munnari.oz.au.
26
27	Abstract
28
29	This document gives an overview of how Uniform Resource Names (URNs) will
30	be resolved. It describes how different URN resolution schemes will fit
31	together, the requirements for the multiple URN schemes, expectations for
32	URN clients, and other general resolution issues.
33
34	This document does not cover any specific resolution schemes, the syntax
35	for URNs, or the format of resolution results. It is expected that these
36	issues (and other URN-related topics) will be covered in different Internet
37	Drafts submitted to the IETF URI Working Group.
38
39	1. Introduction
40
41	A URN (Uniform Resource Name) is the name of a resource within the context
42	of a larger Internet information architecture known as Uniform Resource
43	Identification. URNs are simple text strings that unambiguously identify an
44	Internet resource. Any Internet resource may have multiple names, but all
45	uses of a particular name identify the same resources, as viewed by their
46	publisher.
47
48	Using a URN resolution service, an Internet user or program can retrieve
49	information about the named resource. The minimum set of requirements for
50	URNs are described in [URNR].
51
52	Resolving a URN returns information about that named resource, such as a
53	description of the resource, the location or locations of the resource, and
54	bibliographic information about the resource. URNs differ from URLs
55	(Uniform Resource Locators) described in RFC 1738 [URL] in that URNs allow
56	resources on the Internet to be specified by name instead of by location.
57	URNs return information about the resource, not the resource itself.
58
59	Using URNs has many advantages for identifying resources, including:
60
61	- The information in a resource may move in the future. For example, as
62	some Internet services get too popular for their original hosts, they move
63	to different systems which have different URLs. Also, a service might move
64	from host system to host system with the person who maintains it.
65
66	- Users can easily access metainformation about a resource without
67	accessing the resource itself. A user might want to see the bibliographic
68	information about a resource without getting the resource, particularly if
69	it costs money to get the resource. Other useful metainformation that a
70	user might want to see before accessing a resource includes the name of the
71	maintainer of the resource, the language in which the resource is in, the
72	price of the resource, the requirements of the user before reading the
73	resource, and so on.
74
75	- A resource may exist in many locations on the Internet. By resolving a
76	single URN, the user can get a list of URLs from which to access the
77	resource and more complete bibliographic information from a URC [URC]. This
78	list can include valuable metainformation such as suggestions about the
79	best location for the user to retrieve the resource from based on cost,
80	speed, or other factors.
81
82	It is important to understand that URNs are neither a superset or a subset
83	of URLs: they are different. The difference between URNs and URLs is
84	similar to that between the title of a book and a locator for it on the
85	shelf.
86
87	2. Syntax
88
89	The syntax for URNs is described in [URNS]. This general syntax has
90	provision for multiple, specific URN schemes.
91
92	3. URN Resolution Schemes
93
94	There are many methods for resolving URNs. Each method is called a
95	"scheme". A URN resolution scheme defines the following:
96	- the name of the scheme, described in [URNS]
97	- the syntax for the scheme-specific part of the URN
98	- the transport protocol or protocols used to resolve URN with that scheme
99	- the types of resolution results that the scheme might return
100
101	Having more than one URN resolution scheme allows URNs to be used for such
102	naming schemes as ISBNs (International Standard Book Numbering system),
103	ISSNs (International Standard Serial Numbering system), and other naming
104	schemes that are not currently on the Internet. It also allows for naming
105	schemes that can be resolved in ways that are distributed and not
106	location-specific.
107
108	Each scheme is defined in its own Internet Draft. These drafts must include
109	all the above information, as well as how the scheme meets the requirements
110	in [URNR].
111
112	4. Overview of URN Resolution
113
114	URN resolution can be described in two parts: the resolution request and
115	the resolution result. A resolution request describes the URN to be
116	resolved to the resolution server. A resolution result is the text that is
117	returned from the resolution server; it gives the requested information
118	about the resource named in the URN.
119
120	4.1 Resolution Requests
121
122	A URN is resolved by communicating with a URN resolution service. At a
123	minimum, all URN resolution services provide a request/response system: a
124	single URN is specified, and a single response is returned. The service can
125	be stateless or can preserve state, depending on the communication protocol
126	used. Each resolution request must give enough information to the
127	resolution server that it can completely and unambiguously identify which
128	URN is being specified. More capable URN resolvers may accept queries which
129	select sets of URNs, but their operation is outside the scope of this
130	draft.
131
132	The current query-response system for resolving URNs is quite simple.
133	Future extensions to this system will accommodate more capable query
134	languages.
135
136	4.2 Resolution Results
137
138	The resolution request specifies the information desired in the response.
139	This might be simple list of URLs, or a more informative reply with a great
140	deal of additional information. If possible, the request should be able to
141	indicate the desired format for the response, such as plain text, HTML, or
142	some application specific binary encoding suitable for cryptographic
143	operations.
144
145	The resolution server returns the results of each resolution request in a
146	single response.
147
148	If the resolution request specifies desired formats for the response, the
149	resolution server should attempt to return only those types of results.
150	However, it is acknowledged that this may be impractical or impossible for
151	some resolution servers, and the client should be able to handle (or at
152	least ignore) resolution results that are not of a requested type.
153
154	5. URN Resolution Clients, Proxies, and Caching
155
156	URN clients are allowed to interpret the resolution result and present the
157	user with a better interface than just the text that is returned. For
158	example, an intelligent Gopher-based URN client resolving an HTTP-based URN
159	could go through a Gopher-to-HTTP gateway can select the URLs with the
160	"gopher:" scheme and create a Gopher menu of them. Similarly, an
161	intelligent HTML-based URN client can reformat a resolution result as HTML
162	text with the URLs as links that can be selected.
163
164	In order to make URN resolution available to as many Internet users as
165	possible, it is assumed that resolution may take place through protocol
166	proxies and gateways. Proxies and gateways allow Internet users who do not
167	have URN clients, or whose clients do not speak in all the transport
168	protocols described in the various URN schemes, to resolve URNs. Current
169	proxies and gateways should work well for this purpose, but they should be
170	enhanced and more widely available. Some sites will choose to have local
171	proxies and gateways, while other sites will allow people from outside
172	their site to use their proxies and gateways freely.
173
174	URN resolution clients, proxies, and gateways may choose to cache
175	resolution results in order to speed resolution and to reduce Internet
176	traffic. Caching should only be performed using the native mechanisms in
177	the transport protocols to assure that URNs whose response content changes
178	rapidly are not accidentally cached.
179
180	6. Security Implications
181
182	Attempting to resolve a URN can cause unencoded messages to be sent between
183	two systems on the Internet, and thus can introduce many security concerns.
184	Resolution requests and responses can be logged at the originating site,
185	the recipient site, and intermediary sites along the delivery path. If
186	secure encryption is not used, resolution requests and responses can also
187	be read at any of those sites.
188
189	All the security implications of each transport protocol are probably the
190	same for URNs transported using those protocols.
191
192	7. References
193
194	[URC] Internet-Draft, "URC Scenarios and Requirements". The name of the
195	draft at the time of this writing is "draft-ietf-uri-urc-req-01".
196
197	[URL] RFC 1738, "Uniform Resource Locators (URL)".
198
199	[URNR] RFC 1737, "Functional Requirements for Uniform Resource Names".
200
201	[URNS] Internet-Draft, "Generic URN Syntax". The name of the draft at the
202	time of this writing is "draft-ietf-uri-urn-syntax-00".
203
204	8. Author Contact Information
205
206	Paul E. Hoffman
207	Proper Publishing
208	127 Segre Place
209	Santa Cruz, CA, USA 95060
210	voice: (408) 426-6222
211	phoffman@proper.com
212
213	Ron Daniel Jr.
214	MS B287
215	Los Alamos National Laboratory
216	Los Alamos, NM, USA 87545
217	voice: (505) 665-0597
218	fax: (505) 665-4939
219	rdaniel@lanl.gov
220
221