rfc1736.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 564 行 · 第 1/2 页

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





Kunze                                                           [Page 6]

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.









Kunze                                                           [Page 7]

RFC 1736                Recommendations for IRLs           February 1995


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

   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



Kunze                                                           [Page 8]

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
      Lars-Gunnar Olson, Swedish University of Agriculture
      Mark McCahill, University of Minnesota



Kunze                                                           [Page 9]

RFC 1736                Recommendations for IRLs           February 1995


      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

8. Author's Address

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

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]

































Kunze                                                          [Page 10]