RFC 2276 (rfc2276) - Page 2 of 24

Architectural Principles of Uniform Resource Name Resolution

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