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.

4.8 The set of services is extensible.

   New services can be added over time.

4.9 Locators contain no information about the resource other than that
    required by the access mechanism.

   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.

5. Security Considerations

   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




 
RFC 1736                Recommendations for IRLs           February 1995


   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.

6. Conclusion

   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.

7. Acknowledgements

   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