rfc1736.txt

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

Network Working Group                                           J. Kunze
Request for Comments: 1736                             IS&T, UC Berkeley
Category: Informational                                    February 1995


       Functional Recommendations for Internet Resource Locators

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

1. Introduction

   This document specifies a minimum set of requirements for Internet
   resource locators, which convey location and access information for
   resources.  Typical examples of resources include network accessible
   documents, WAIS databases, FTP servers, and Telnet destinations.

   Locators may apply to resources that are not always or not ever
   network accessible.  Examples of the latter include human beings and
   physical objects that have no electronic instantiation (that is,
   objects without an existence completely defined by digital objects
   such as disk files).

   A resource locator is a kind of resource identifier.  Other kinds of
   resource identifiers allow names and descriptions to be associated
   with resources.  A resource name is intended to provide a stable
   handle to refer to a resource long after the resource itself has
   moved or perhaps gone out of existence.  A resource description
   comprises a body of meta-information to assist resource search and
   selection.

   In this document, an Internet resource locator is a locator defined
   by an Internet resource location standard.  A resource location
   standard in conjunction with resource description and resource naming
   standards specifies a comprehensive infrastructure for network based
   information dissemination.  Mechanisms for mapping between locators,
   names, and descriptive identifiers are beyond the scope of this
   document.

2. Overview of Problem

   Network-based information resource providers require a method of
   describing the location of and access to their resources.
   Information systems users require a method whereby client software
   can interpret resource access and location descriptions on their



Kunze                                                           [Page 1]

RFC 1736                Recommendations for IRLs           February 1995


   behalf in a relatively transparent way.  Without such a method,
   transparent and widely distributed, open information access on the
   Internet would be difficult if not impossible.

2.1 Defining the General Resource Locator

   The requirements listed in this document impose restrictions on the
   general resource locator.  To better understand what the Internet
   resource locator is, the following general locator definition
   provides some contrast.

        Definition:  A general resource locator is an object
                     that describes the location of a resource.

   This definition deliberately allows many degrees of freedom in order
   to contain the furthest reaches of the wide-ranging debate on
   resource location standards.  Vast as it is, this problem space is a
   useful backdrop for discussion of the requirements (later) that
   generate a smaller, more manageable problem space.  A resource
   location standard shrinks the space again by applying additional
   requirements.

   Consider the definition in four parts: (1) A general resource locator
   is an object (2) that describes (3) the location of (4) a resource.

2.1.1.  A general resource locator is an object...

   The object could be a complex data structure.  It could be a
   contiguous sequence of bytes.  It could be a pair of latitude-
   longitude coordinates, or a three-color road map printed on paper.
   It could be a sequence of characters that are capable of being
   printed on paper.

2.1.2.  ...that describes

   In the fully general case, there are many ways that a resource
   locator could describe the location.  It could employ a graphical or
   natural language description.  It could be heavily encoded or
   compressed.  It could be lightly encoded and readily understandable
   by human beings.  The description could be a multi-level hierarchy
   with common semantics at each level.  It could be a multi-level
   hierarchy with common semantics at only the first two levels, where
   semantics below the second level depend on the value given at the
   first level.  These are just a few possibilities.







Kunze                                                           [Page 2]

RFC 1736                Recommendations for IRLs           February 1995


2.1.3.  ...the location of

   A resource locator describes a location but never guarantees that
   access may be established.  While access is often desired when
   clients follow location instructions given in a conformant resource
   locator, the resource need not exist any longer or need not exist
   yet.  Indeed it may never exist, even though the locator continues to
   describe a location where a resource might exist (e.g., it might be
   used as a placeholder with resource availability contingent upon an
   event such as a payment).

   Furthermore, the nature of certain potential resources, especially
   animate beings or physical objects with no electronic instantiation,
   makes network access meaningless in some cases; such resources have
   locators that would imply non-networked access, but again, access is
   not guaranteed.

2.1.4.  ...a resource.

   A resource can be many things.  Besides the non-networked or non-
   electronic resources just mentioned, familiar examples are an
   electronic document, an image, a server (e.g., FTP, Gopher, Telnet,
   HTTP), or a collection of items (e.g., Gopher menu, FTP directory,
   HTML page).  Other examples accompany multi-function protocols such
   as Z39.50, which can perform single round trip network access,
   session-oriented search refinement, and index browsing.

2.2 Producers and Interpreters of Resource Locators

   Central to the discussion of locator requirements is the issue of
   parsability.  This is the ability of an agent to recognize or
   understand a locator in whole or in part.  Discussion may be assisted
   by clearly distinguishing the two main actions associated with
   locators.

   Resource locators are both produced and interpreted.  Producers are
   bound by the resource location standards that are in turn bound by
   requirements listed in this document.  Interpreters of locators are
   not bound by the requirements; they are beneficiaries of them.

2.2.1 Resource Locator Interpreters

   A resource locator is interpreted by interpreting agents, which in
   this document are simply called interpreters.  Interpreters may be
   either human beings or software.  Along the way to establishing
   access based on information in a locator, one or more interpreters
   may be employed.  Some examples of multiple interpreters processing a
   single locator illustrate the concept that a resource locator may be



Kunze                                                           [Page 3]

RFC 1736                Recommendations for IRLs           February 1995


   understandable only in part by each of several interpreters, but
   understandable in its entirety by a combination of interpreters.

   In the first example, a software interpreter recognizes enough of a
   locator to understand to which external agent it needs to forward it.
   Here, the external agent might be a user and the locator a library
   call number; the software forwards the locator simply by displaying
   it. The agent might be a network software layer specializing in a
   particular communications protocol; once the service is recognized,
   the locator is forwarded to it along with an access request.

   In another example, a human interpreter might also recognize enough
   of a locator to understand where to forward it.  Here, the person
   might be a user who recognizes a library call number as such but who
   does not understand the location information encoded in it; the
   person forwards it to a library employee (an external agent) who
   knows how to establish access to the library resource.

   A prerequisite to interpreting a locator is understanding when an
   object in question actually is a locator, or contains one or more
   locators.  Some constrained environments make this question easy to
   answer, for example, within HTML anchors or Gopher menu items.  Less
   constrained environments, such as within running text, make it more
   difficult to answer without well-defined assumptions.  A resource
   location standard needs to make any such assumptions explicit.

2.2.2 Resource Locator Producers

   Resource locators are produced in many ways, often by an agent that
   also interprets them.  The provider of a resource may produce a
   locator for it, leaving the locator in places where it is intended to
   be discovered, such as an HTML page, a Gopher menu, or an
   announcement to an e-mail list.

   Non-providers of resources can be major producers of locators; for
   example, WWW client software produces locators by translating foreign
   resource locators (e.g., Gopher menu items) to its own format.  Some
   locator databases (e.g., Archie) have been maintained by automated
   processes that produce locators for hundreds of thousands of FTP
   resources that they "discover" on the Internet.

   Users are major producers of resource locators.  A user constructing
   one to share with others is responsible for conformance with locator
   standards.  Sometimes a user composes a resource locator based on an
   educated guess and submits it to client software with the intent of
   establishing access.  Such a user is a producer in a sense, but if
   the locator is purely for personal consumption the user is not bound
   by the requirements.  In fact, some client software may offer as a



Kunze                                                           [Page 4]

RFC 1736                Recommendations for IRLs           February 1995


   service to translate abbreviated, non-conformant locators entered by
   users into successful access instructions or into conformant locators
   (e.g., by adding a domain name to an unqualified hostname)

2.3 Uniqueness of Resource Locators

   The topic of a "uniqueness" requirement for resource locators has
   been discussed a great deal.  This document considers the following
   aspects of uniqueness, but deliberately rejects them as requirements.
   It is incumbent upon a resource location standard that takes on this
   topic to be clear about which aspects it addresses.

2.3.1. Uniqueness and Multiple Copies of a Resource

   A uniqueness requirement might dictate that no identical copies of a
   resource may exist.  This document makes no such requirement.

2.3.2. Uniqueness and Deterministic Access

   A uniqueness requirement might dictate that the same resource
   accessed in one attempt will also be the result of any other
   successful attempt.  This document makes no such requirement, nor
   does it define "sameness".  It is inappropriate for a resource
   location standard to define "sameness" among resources.

2.3.3. Uniqueness and Multiple Locators

   A uniqueness requirement might dictate that a resource have no more
   than one locator unless all such locators be the same.  This document
   makes no such requirement, nor does it define "sameness" among
   locators (which a standard might do using, for example,
   canonicalization rules).

2.3.4. Uniqueness, Ambiguity, and Multiple Objects per Access

   A uniqueness requirement might dictate that a resource locator
   identify exactly one object as opposed to several objects.  This
   document makes no general definition of what constitutes one object,
   several objects, or one object consisting of several objects.

3. Resource Access and Availability

   A locator never guarantees access, but establishing access is by far
   the most important intended application of a resource locator.  While
   it is considered ungracious to advertize a locator for a resource
   that will never be accessible (whether a "networkable" resource or
   not), it is normal for resource access to fail at a rate that
   increases with the age of the locator used.



Kunze                                                           [Page 5]