RFC 1737 (rfc1737) - Page 1 of 7
Functional Requirements for Uniform Resource Names
Alternative Format: Original Text Document
Network Working Group K. Sollins
Request for Comments: 1737 MIT/LCS
Category: Informational L. Masinter
Xerox Corporation
December 1994
Functional Requirements for Uniform Resource Names
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
1. Introduction
This document specifies a minimum set of requirements for a kind of
Internet resource identifier known as Uniform Resource Names (URNs).
URNs fit within a larger Internet information architecture, which in
turn is composed of, additionally, Uniform Resource Characteristics
(URCs), and Uniform Resource Locators (URLs). URNs are used for
identification, URCs for including meta-information, and URLs for
locating or finding resources. It is provided as a basis for
evaluating standards for URNs. The discussions of this work have
occurred on the mailing list and at the URI Working
Group sessions of the IETF.
The requirements described here are not necessarily exhaustive; for
example, there are several issues dealing with support for
replication of resources and with security that have been discussed;
however, the problems are not well enough understood at this time to
include specific requirements in those areas here.
Within the general area of distributed object systems design, there
are many concepts and designs that are discussed under the general
topic of "naming". The URN requirements here are for a facility that
addresses a different (and, in general, more stringent) set of needs
than are frequently the domain of general object naming.
The requirements for Uniform Resource Names fit within the overall
architecture of Uniform Resource Identification. In order to build
applications in the most general case, the user must be able to
discover and identify the information, objects, or what we will call
in this architecture resources, on which the application is to
operate. Beyond this statement, the URI architecture does not define
"resource." As the network and interconnectivity grow, the ability
to make use of remote, perhaps independently managed, resources will
Sollins & Masinter