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.








 
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




 
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.