URI Resolution Services Necessary for URN Resolution
RFC 2483

Document Type RFC - Experimental (January 1999; No errata)
Authors Ron Daniel  , Michael Mealling 
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 2483 (Experimental)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      M. Mealling
Request for Comments: 2483                     Network Solutions, Inc.
Category: Experimental                                  R. Daniel, Jr.
                                        Los Alamos National Laboratory
                                                          January 1999

                        URI Resolution Services
                      Necessary for URN Resolution

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.


   Retrieving the resource identified by a Uniform Resource Identifier
   (URI) [1] is only one of the operations that can be performed on a
   URI.  One might also ask for and get a list of other identifiers that
   are aliases for the original URI or a bibliographic description of
   the resource the URI denotes, for example. This applies to both
   Uniform Resource Names (URNs) and Uniform Resource Locators (URLs).
   Uniform Resource Characteristics (URCs) are discussed in this
   document but only as descriptions of resources rather than

   A service in the network providing access to a resource may provide
   one or some of these options, but it need not provide all of them.
   This memo specifies an initial set of these operations that can be
   used to describe the interactions provided by a given access service.
   It also suggests guidelines that should be adhered to when those
   operations are encoded in a protocol.

1. Introduction

   In the course of formulating current proposals [2] regarding URNs
   [3], it became apparent that requiring servers to manage all of the
   desired functions or requiring clients to process varied information
   returned by a server was unrealistic and a barrier to adoption. There
   needed to be some way for a client to be able to identify a server
   that specialized in the complex and another that specialized in the

Mealling & Daniel             Experimental                      [Page 1]
RFC 2483                URI Resolution Services             January 1999

   simple (but fast). Also, in subsequent conversations it became
   obvious that, in most cases, some of the operations were
   inappropriate or difficult for certain identifiers.

   The Problem

   In the process of learning about a resource in the Internet, there
   are a variety of possible functions that may be important and/or
   useful, such as discovery of locators, names, descriptions, and
   accessing the resource itself. A given service may support only a
   subset of these; hence, it is important to describe such an access
   service by the types of functions supported and the resources of
   which it has some knowledge. For example, in the framework for an RDS
   described in [5] the RDS itself may provide URLs [6][7], while the
   resolvers may provide descriptions, URLs, or even the resources
   themselves. The design of an RDS, as proposed in RFC 2168 [2], may be
   more generous and provide all of the above.

   This problem requires some well understood set of identifiers that
   specify those operations. But an exhaustive set would both be
   impossible and not very necessary. Thus, this document will list
   several operations, as well as, lay out requirements for specifying
   new operations.

   The purpose of this document is to define a list of such functions
   and short names for them and then use them in defining the interface
   to an access service. Previous versions of this document referred to
   services where the arguments were specific types of URIs such as URNs
   or URLs.  These services were called "N2L" and "L2L",for example.
   Their use has been changed in favor of the more general URI form.

   Design Criteria

   To meet these requirements a fairly simple design criteria was used.
   The need to identify the operation with some token such that its
   operands, algorithm, and errors were known proved sufficient to meet
   these requirements.

2. General Specification

   To provide a framework both for the specifications in this document
   and for future work to be written by others, the guidelines below are
   suggested for documents that seek to specify new operations. Any
   specification of a member of this set of operations should address
   these issues with respect to its operands, algorithm, output, and

Mealling & Daniel             Experimental                      [Page 2]
RFC 2483                URI Resolution Services             January 1999

   Due to the small number of listed functions, a registration mechanism
   was dismissed as premature. If this list grows, a registration
   mechanism will probably be needed.
Show full document text