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




 
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.




 
RFC 1736                Recommendations for IRLs           February 1995


   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