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.

4. Requirements List for Internet Resource Locators

   This list of requirements is applied to the set of general locators
   defined in section 2.1.  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.

4.1 Locators are transient.

   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.






 
RFC 1736                Recommendations for IRLs           February 1995


4.2 Locators have global scope.

   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.

4.3 Locators are parsable.

   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:

4.3.1  A given kind of locator may still be parsable even if a given
       interpreter cannot parse it.

4.3.2  Parsable by users does not imply readily parsable by untrained
       users.

4.3.3  A given locator need not be completely parsable by any one
       interpreter as long as a combination of interpreters can parse
       it completely.

4.4 Locators can be readily distinguished from naming and descriptive
    identifiers that may occupy the same name space.

   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.

4.5 Locators are "transport-friendly".

   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.

4.6 Locators are human transcribable.

   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.










 
RFC 1736                Recommendations for IRLs           February 1995


4.7 An Internet locator consists of a service and an opaque parameter
    package.