Architectural Principles of Uniform Resource Name Resolution
RFC 2276
| Document | Type |
RFC - Informational
(January 1998; No errata)
Updated by RFC 3401
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text pdf html 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
Show full document text