W3C home > Mailing lists > Public > uri@w3.org > May 1995

New Internet Draft: draft-ietf-uri-urn-res-descrip-00

From: Paul Hoffman <ietf-lists@proper.com>
Date: Mon, 1 May 1995 09:19:39 -0700
Message-Id: <v02120c0cabcaba16d628@[]>
To: uri@bunyip.com
Cc: internet-drafts@CNRI.Reston.VA.US
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 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

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


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

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

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

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

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

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

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

Ron Daniel Jr.
MS B287
Los Alamos National Laboratory
Los Alamos, NM, USA 87545
voice:  (505) 665-0597
fax:  (505) 665-4939
Received on Monday, 1 May 1995 12:19:05 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:30 UTC