RFC 2276 (rfc2276) - Page 2 of 24
Architectural Principles of Uniform Resource Name Resolution
Alternative Format: Original Text Document
RFC 2276 Uniform Resource Name Resolution January 1998
1. Introduction
The purpose of this document is to lay out the engineering criteria
for what we will call here a Resolver Discovery Service (RDS), a
service to help in the learning about URN (Uniform Resource Name)
resolvers. The term "resolver" is used in this document to indicate
a service that translates URNs to URLs (Uniform Resource Locators) or
URCs (Uniform Resource Characteristics). Some resolvers may provide
direct access to resources as well. An RDS helps in finding a
resolver to contact for further resolution. It is worth noting that
some RDS designs may also incorporate resolver functionality. This
function of URN resolution is a component of the realization of an
information infrastructure. In the case of this work, that
infrastructure is to be available, "in the Internet" or globally, and
hence the solutions to the problems we are addressing must be
globally scalable. In this document, we are focussing specifically
on the design of RDS schemes.
The Uniform Resource Identifier Working Group defined a naming
architecture, as demonstrated in a series of three RFCs 1736 [1],
1737 [2], and 1738 [3]. Although several further documents are
needed to complete the description of that architecture, it
incorporates three core functions often associated with "naming":
identification, location, and mnemonics or semantics. By location,
we mean fully-qualified Domain Names or IP addresses, possibly
extended with TCP ports and/or local identifiers, such as pathnames.
Names may provide the ability to distinguish one resource from
another, by distinguishing their "names". Names may help to provide
access to a resource by including "location" information. In
addition, names may have other semantic or mnemonic information that
either helps human users remember or figure out the names, or
includes other semantic information about the resource being named.
The URI working group concluded that there was need for persistent,
globally unique identifiers, distinct from location or other semantic
information; these were called URNs. These "names" provide identity,
in that if two of them are "the same" (under some simple rule of
canonicalization), they identify the same resource. Furthermore, the
group decided that these "names" were generally to be for machine,
rather than human, consumption. Finally, with these guidelines for
RDS's, this group has recognized the value of the separation of name
assignment management from name resolution management.
In contrast to URNs, one can imagine a variety human-friendly naming
(HFN) schemes supporting different suites of applications and user
communities. These will need to provide mappings to URNs in tighter
or looser couplings, depending on the namespace. It is these HFNs
that will be mnemonic, content-full, and perhaps mutable, to track
changes in use and semantics. They may provide nicknaming and other
Sollins Informational