Requirements for URN Resolution Systems
draft-girod-urn-res-require-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Dr. Karen R. Sollins , Lewis Girod | ||
| Last updated | 1996-06-13 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
This paper presents a set of requirements for systems that resolve URNs into hints for locating resources. Hints are a type of metadata that provide information about locating a resource, including but not limited to URLs and pointers to other resolution systems. The requirements fall into three broad areas: usability, security, and evolvability. With those in mind, the paper reviews what we have been able to learn about the NAPTR proposal. The NAPTR proposal has grown out of a set of several different URN resolution proposals; it uses the existing DNS infrastructure to store and serve resolution information. To this end they introduce a new kind of DNS entry called a NAPTR, or Naming Authority PoinTeR. The review of the NAPTR proposal includes our wishlist for extensions and modifications to it that would add evolutionary paths to the design without sacrificing ease of implementation. The paper then presents a sketch of a more extensive URN resolution system, presented in order to demonstrate the need for evolution in any URN resolution proposal.
Authors
Dr. Karen R. Sollins
Lewis Girod
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)