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


       <span class="h1">Functional Recommendations for Internet Resource Locators</span>

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.

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>

   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.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Overview of Problem</span>

   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



<span class="grey">Kunze                                                           [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc1736">RFC 1736</a>                Recommendations for IRLs           February 1995</span>


   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.

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a> Defining the General Resource Locator</span>

   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.

<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>.  A general resource locator is an object...</span>

   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.

<span class="h4"><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a>.  ...that describes</span>

   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.







<span class="grey">Kunze                                                           [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc1736">RFC 1736</a>                Recommendations for IRLs           February 1995</span>


<span class="h4"><a class="selflink" id="section-2.1.3" href="#section-2.1.3">2.1.3</a>.  ...the location of</span>

   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.

<span class="h4"><a class="selflink" id="section-2.1.4" href="#section-2.1.4">2.1.4</a>.  ...a resource.</span>

   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.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a> Producers and Interpreters of Resource Locators</span>

   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.

<span class="h4"><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a> Resource Locator Interpreters</span>

   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



<span class="grey">Kunze                                                           [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc1736">RFC 1736</a>                Recommendations for IRLs           February 1995</span>


   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.

<span class="h4"><a class="selflink" id="section-2.2.2" href="#section-2.2.2">2.2.2</a> Resource Locator Producers</span>

   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



<span class="grey">Kunze                                                           [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc1736">RFC 1736</a>                Recommendations for IRLs           February 1995</span>


   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)

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a> Uniqueness of Resource Locators</span>

   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.

<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a>. Uniqueness and Multiple Copies of a Resource</span>

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

<span class="h4"><a class="selflink" id="section-2.3.2" href="#section-2.3.2">2.3.2</a>. Uniqueness and Deterministic Access</span>

   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.

<span class="h4"><a class="selflink" id="section-2.3.3" href="#section-2.3.3">2.3.3</a>. Uniqueness and Multiple Locators</span>

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

<span class="h4"><a class="selflink" id="section-2.3.4" href="#section-2.3.4">2.3.4</a>. Uniqueness, Ambiguity, and Multiple Objects per Access</span>

   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.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Resource Access and Availability</span>

   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.



<span class="grey">Kunze                                                           [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc1736">RFC 1736</a>                Recommendations for IRLs           February 1995</span>


   Resource access can fail for many reasons.  Providers fundamentally
   affect accessibility by moving, replacing, or deleting resources over
   time.  The frequency of such changes depends on the nature of the
   resource and provider service practices, among other things.  A
   locator that conforms to a location standard but fails for one of
   these reasons is called "invalid" for the purposes of this document;
   the term invalid locator does not apply to malformed or non-
   conformant locators.  Resource naming standards address the problem
   of invalid locators.

   Ordinary provider support policies may cause resources to be
   inaccessible during predictable time periods (e.g., certain hours of
   the day, or days of the year), or during periods of heavy system
   loading.  Rights clearance restrictions impossible to express in a
   locator also affect accessibility for certain user populations.
   Heavy network load can also prevent access.  In such situations, this
   document calls a resource "unavailable".  A locator can both be valid
   and identify a resource that is unavailable.  Resource description
   standards address, among other things, some aspects of resource
   availability.

   In general, the probability with which a given resource locator leads
   to successful access decreases over time, and depends on conditions
   such as the nature of the resource, support policies of the provider,
   and loading of the network.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Requirements List for Internet Resource Locators</span>

   This list of requirements is applied to the set of general locators
   defined in <a href="#section-2.1">section 2.1</a>.  The resulting subset, called Internet
   locators in this document, is suitable for further refinement by an
   Internet resource location standard.  Some requirements concern
   locator encoding while others concern locator function.

   One requirement from the original draft list was dropped after
   extensive discussion revealed it to be impractical to meet.  It
   stated that with a high degree of reliability, software can recognize
   Internet locators in certain relatively unstructured environments,
   such as within running ASCII text.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a> Locators are transient.</span>

   The probability with which a given Internet resource locator leads to
   successful access decreases over time.  More stable resource
   identifier schemes are addressed in resource naming standards and are
   outside the scope of a resource location standard.





<span class="grey">Kunze                                                           [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc1736">RFC 1736</a>                Recommendations for IRLs           February 1995</span>


<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a> Locators have global scope.</span>

   The name space of resource locators includes the entire world.  The
   probability of successful access using an Internet locator depends in
   no way, modulo resource availability, on the geographical or Internet
   location of the client.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a> Locators are parsable.</span>

   Internet locators can be broken down into complete constituent parts
   sufficient for interpreters (software or human) to attempt access if
   desired.  While these requirements do not bind interpreters, three
   points bear emphasizing:

<span class="h4"><a class="selflink" id="section-4.3.1" href="#section-4.3.1">4.3.1</a>  A given kind of locator may still be parsable even if a given</span>
<span class="h4">       interpreter cannot parse it.</span>

<span class="h4"><a class="selflink" id="section-4.3.2" href="#section-4.3.2">4.3.2</a>  Parsable by users does not imply readily parsable by untrained</span>
<span class="h4">       users.</span>

<span class="h4"><a class="selflink" id="section-4.3.3" href="#section-4.3.3">4.3.3</a>  A given locator need not be completely parsable by any one</span>
<span class="h4">       interpreter as long as a combination of interpreters can parse</span>
       it completely.

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a> Locators can be readily distinguished from naming and descriptive</span>
<span class="h3">    identifiers that may occupy the same name space.</span>

   During a transition period (of possibly indefinite length), other
   kinds of resource identifier are expected to co-exist in data
   structures along with Internet locators.

<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a> Locators are "transport-friendly".</span>

   Internet locators can be transmitted from user to user (e.g, via e-
   mail) across Internet standard communications protocols without loss
   or corruption of information.

<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a> Locators are human transcribable.</span>

   Users can copy Internet locators from one medium to another (such as
   voice to paper, or paper to keyboard) without loss or corruption of
   information.  This process is not required to be comfortable.









<span class="grey">Kunze                                                           [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc1736">RFC 1736</a>                Recommendations for IRLs           February 1995</span>


<span class="h3"><a class="selflink" id="section-4.7" href="#section-4.7">4.7</a> An Internet locator consists of a service and an opaque parameter</span>
<span class="h3">    package.</span>

   The parameter package has meaning only to the service with which it
   is paired, where a service is an abstract access method.  An abstract
   access method might be a software tool, an institution, or a network
   protocol.  The parameter package might be service-specific access
   instructions.  In order to protect creative development of new
   services, there is an extensible class of services for which no
   parameter package semantics common across services may be assumed.

<span class="h3"><a class="selflink" id="section-4.8" href="#section-4.8">4.8</a> The set of services is extensible.</span>

   New services can be added over time.

<span class="h3"><a class="selflink" id="section-4.9" href="#section-4.9">4.9</a> Locators contain no information about the resource other than that</span>
<span class="h3">    required by the access mechanism.</span>

   The purpose of an Internet locator is only to describe the location
   of a resource, not other properties such as its type, size,
   modification date, etc.  These and other properties belong in a
   resource description standard.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>

   While the requirements have no direct security implications,
   applications based on standards that fulfill them may need to
   consider two potential vulnerabilities.  First, because locators are
   transient, a client using an invalid locator might unwittingly gain
   access to a resource that was not the intended target.  For example,
   when a hostname becomes unregistered for a period of time and then
   re-registered, a locator that was no longer valid during that period
   might once again lead to a resource, but perhaps to one that only
   pretends to be the original resource.

   Second, because a locator consists of a service and a parameter
   package, potentially enormous processing freedom is allowed,
   depending on the individual service.  A server is vulnerable unless
   it suitably restricts its input parameters.  For example, a server
   that advertizes locators for certain local filesystem objects may
   inadvertently open a door through which other filesystem objects can
   be accessed.

   A client is also vulnerable unless it understands the limitations of
   the service it is using.  For example, a client trusting a locator
   obtained from an uncertain source might inadvertently trigger a
   mechanism that applies charges to a user account.  Having a clear
   definition of service limitations could help alleviate some of these



<span class="grey">Kunze                                                           [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc1736">RFC 1736</a>                Recommendations for IRLs           February 1995</span>


   concerns.

   For services that by nature offer a great deal of user freedom
   (remote login for example), the pre-specification of user commands
   within a locator presents vulnerabilities.  With careful command
   screening, the deleterious effects of unknowingly executing (at the
   client or server) an embedded command such as "rm -fr *" can be
   avoided.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Conclusion</span>

   Resource location standards, which define Internet resource locators,
   give providers the means to describe access information for their
   resources.  They give client developers the ability to access
   disparate resources while hiding access details from users.

   Several minimum requirements distinguish an Internet locator from a
   general locator.  Internet resource locators are impermanent handles
   sufficiently qualified for resource access not to depend in general
   on client location.  Locators can be recognized and parsed, and can
   be transmitted unscathed through a variety of human and Internet
   communication mechanisms.

   An Internet resource locator consists of a service and access
   parameters meaningful to that service.  The form of the locator does
   not discourage the addition of new services or the migration to other
   resource identifiers.  A clean distinction between resource location,
   resource naming, and resource description standards is preserved by
   limiting Internet locators to no more information than what is
   required by an access mechanism.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>

   The core requirements of this document arose from a collaboration of
   the following people at the November 1993 IETF meeting in Houston,
   Texas.

      Farhad Ankelesaria, University of Minnesota
      John Curran, NEARNET
      Peter Deutsch, Bunyip
      Alan Emtage, Bunyip
      Jim Fullton, CNIDR
      Kevin Gamiel, CNIDR
      Joan Gargano, University of California at Davis
      John Kunze, University of California at Berkeley
      Clifford Lynch, University of California
      Lars-Gunnar Olson, Swedish University of Agriculture
      Mark McCahill, University of Minnesota



<span class="grey">Kunze                                                           [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc1736">RFC 1736</a>                Recommendations for IRLs           February 1995</span>


      Michael Mealing, Georgia Tech
      Mitra, Pandora Systems
      Pete Percival, Indiana University
      Margaret St. Pierre, WAIS, Inc.
      Rickard Schoultz, KTH
      Janet Vratny, Apple Computer Library
      Chris Weider, Bunyip

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Author's Address</span>

   John A. Kunze
   Information Systems and Technology
   293 Evans Hall
   Berkeley, CA  94720

   Phone: (510) 642-1530
   Fax:   (510) 643-5385
   EMail: jak@violet.berkeley.edu

































Kunze                                                          [Page 10]
</pre>