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
