Architectural Principles of Uniform Resource Name Resolution
RFC 2276
Document | Type |
RFC - Informational
(January 1998; No errata)
Updated by RFC 3401
|
|
---|---|---|---|
Author | Karen Sollins | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2276 (Informational) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group K. Sollins Request for Comments: 2276 MIT/LCS Category: Informational January 1998 Architectural Principles of Uniform Resource Name Resolution Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document addresses the issues of the discovery of URN (Uniform Resource Name) resolver services that in turn will directly translate URNs into URLs (Uniform Resource Locators) and URCs (Uniform Resource Characteristics). The document falls into three major parts, the assumptions underlying the work, the guidelines in order to be a viable Resolver Discovery Service or RDS, and a framework for designing RDSs. The guidelines fall into three principle areas: evolvability, usability, and security and privacy. An RDS that is compliant with the framework will not necessarily be compliant with the guidelines. Compliance with the guidelines will need to be validated separately. Table of Contents 1. Introduction..................................................2 2. Assumptions...................................................5 3. Guidelines....................................................7 3.1 Evolution.....................................................7 3.2 Usability....................................................10 3.2.1 The Publisher................................................11 3.2.2 The Client...................................................12 3.2.3 The Management...............................................13 3.3 Security and Privacy.........................................14 4. The Framework................................................18 5. Acknowledgements.............................................23 6. References...................................................23 7. Author's Address.............................................23 8. Full Copyright Statement.....................................24 Sollins Informational [Page 1] 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 nameShow full document text