rfc2483.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 900 行 · 第 1/3 页

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.

Abstract

   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
   identifiers.

   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
   errors.





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.

   Also, due to the experimental nature of this document and the systems
   that use its specifications, the use of words like MUST and SHALL are
   limited. Where used they reflect a case where this specification
   could cause harm to existing, non-experimental systems such as HTTP
   and URNs.  Thus, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" in this document are to be interpreted as described in
   RFC 2119.

2.1 Operands

   Operands must contain the following pieces of information:

      * name of the operation
      * case insensitive mnemonic for the operation
      * number of operands
      * type of each operand
      * format of each operand

2.2 Algorithm

   The exact algorithm for the operation must either be specified
   completely or it must be considered opaque and defined by the server
   or application.

2.3 Output

   Output must specify one of the following:

      * there is no output
      * the output is undefined
      * the output itself and its content
      * the fact that the output is an object and the object's
        type and format
      * any non-protocol specific errors

2.4 Error Conditions

   All errors that are considered applicable across all implementations
   and application environments must be included. Errors that depend on
   the system conveying the service are not included. Thus, many of the
   expected errors such as service availability or operation syntax are
   not included in this document since they are implementation
   dependent.



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


2.5 Security Considerations

   Any security considerations relating to the service provided must be
   specified. This does NOT include considerations dealing with the
   protocol used to convey the service or to those that normally
   accompany the results of the service. For example, a service that
   returned a single URL would need to discuss the situation where
   someone maliciously inserts an incorrect URL into the resolver but
   NOT the case where someone sends personal information across the
   Internet to the resource identified by the correct URL.

3. Encoding The Operations

   To be useful, these operations have to be used within some system or
   protocol. In many cases, these systems and protocols will place
   restrictions on which operations make sense and how those that do are
   syntactically represented. It is sufficient for those protocols to
   define new operations within their own protocol specification
   documents but care should be taken to make this fact well known.

   Also, a given system or protocol will have its own output
   specifications that may restrict the output formats of a given
   operation.  Additionally, a given protocol may have better solution
   for output than the ones given here. For example, the result of an
   operation that converts a URI to more than one URL may be encoded in
   a protocol-specific manner that conveys information about the
   closeness of each resource on the network.

   Thus, the requirements on encoding these operations within a given
   system are as follows:

      * which subset of the operations are allowed
      * how the operator is encoded
      * how the operands are encoded
      * how the error codes are returned

   The text/uri-list MIME Media Type is specified in Section 5. This
   Media Type is merely a suggestion for experimental systems that need
   a simple implementation. It is included here merely as an example to
   show completeness (however simple it may be).











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


4. The Incomplete Set

4.1 I2L (URI to URL)

      * Name: URI to URL
      * Mnemonic: I2L
      * Number of Operands: 1
      * Type of Each Operand: First operand is a URI.
      * Format of Each Operand: First operand is encoded as a URI.
      * Algorithm: Opaque
      * Output: One and only one URL
      * Errors Conditions:
           o Malformed URI
           o URI is syntactically valid but does not exist in any form.
           o URI exists but there is no available output from this
             operation.
           o URI existed in the past but nothing is currently known
             about it.
           o Access denied

      * Security Considerations:
           o Malicious Redirection
             One of the fundamental dangers related to any service such
             as this is that a malicious entry in a resolver's database
             will cause clients to resolve the URI into the wrong URL.
             The possible intent may be to cause the client to retrieve
             a resource containing fraudulent or damaging material.
           o Denial of Service
             By removing the URL to which the URI maps, a malicious
             intruder may remove the client's ability to retrieve the
             resource.

   This operation is used to map a single URI to a single URL. It is
   used by lightweight clients that do not have the ability to select
   from a list of URLs or understand a URC. The algorithm for this
   mapping is dependent on the URI scheme.

4.2 I2Ls (URI to URLs)

      * Name: URI to URLs
      * Mnemonic: I2LS
      * Number of Operands: 1
      * Type of Each Operand: First operand is a URI.
      * Format of Each Operand: First operand is encoded as a URI.
      * Algorithm: Opaque
      * Output: A list of zero or more URLs
      * Errors:
           o Malformed URI



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


           o URI is syntactically valid but does not exist in any form.
           o URI exists but there is no available output from this
             operation.
           o URI existed in the past but nothing is currently known
             about it.
           o Access denied
      * Security Considerations:
           o Malicious Redirection (see I2L)
           o Denial of Service (see I2L)

   This operation is used to map a single URI to 0 or more URLs. It is
   used by a client that can pick from a list of URLs based on some
   criteria that are important to the client. The client should not make
   any assumptions about the order of the URLs returned. No matter what