rfc1862.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

      authentication.

   Given a common set of management controls needed, a common protocol
   would allow for simplified management of a collection of caching and
   replicating servers since you would be able to both control them with
   a single set of commands and query them about their capabilities. A
   common language/protocol would also allow different implementations
   to interoperate.

   Replicating or caching information immediately raises issues of
   billing, access control and authentication. Ignoring authentication
   and access control issues simplifies the replication and caching
   problem a great deal. Exactly who is running the replication or
   caching server makes a big difference in how you approach this issue.
   If the information publisher runs a set of servers, they can easily
   handle billing and authentication. On the other hand, if an
   organization is running a cache on its firewall (a boundary cache),
   and purchasing information from a vendor, there are sticky issues
   regarding intellectual property in this scenario.

   Selecting an appropriate cache or replica of a database is simple in
   the case of a captive user group (for instance a company behind a
   firewall). In this case, configuring the user's software to go
   through one or more boundary caches/replication servers directs the
   users to the closest server. In the more general case, there are
   several replicated/cached copies of an object, so you may receive
   several URLs when you resolve a URN. How do you select the best URL?

   Either client developers create ad hoc performance metrics or (in an
   ideal world) the lower level protocols would give the client



McCahill, et al              Informational                      [Page 6]

RFC 1862                  IAB Workshop Report              November 1995


   application some guidance about the "closest" copy of the object.  In
   other words, if better information about network performance was
   available from lower levels of the protocol stack, applications would
   not have to build ad hoc models of network topology

   We did not model the functions of a cache/replication server in
   detail, but we did an (incomplete) model of some of the functions
   (see Figure 1). The idea here was to start work on a general form
   which might include features such as a push function for use in both
   maintaining consistency and in preloading information that the
   information publisher believes will be requested in the near future.

   Preloading information via a push command might be a function of
   observed behavior patterns (when you ask for A you'll probably want B
   and C). The decision about what to preload can be made either by the
   information publisher or by the cache server. The cache server has
   the advantage that it has better knowledge of the use patterns of its
   community. The distributed nature of links to other servers also
   limit the knowledge of a single information publisher. In any case,
   being able to accurately predict usage patterns can result in
   significant performance enhancements for caches.

Figure 1: a rough cut at functions

                 requests from client (in)
                           |
                           |
                           |
                          \|/
                  +---------------------+
                  |                     |     (management)
                  | cache/replicated db |<--- commands from admins,
                  |                     |     publishers, caches
                  +---------------------+
                           |
                           |
                           |
                          \|/
         requests sent to information providers (out)

         in: (requests from a client)

   - give me meta-info about cached object (how up-to-date,
     ttl, expiry, signatures/checksum, billing information )

   - give me the object

   - go get the object from the net



McCahill, et al              Informational                      [Page 7]

RFC 1862                  IAB Workshop Report              November 1995


   - cache, what objects should I pre-fetch?
     (this assumes that the client software believes that the
     cache/replica has some knowledge of use patterns and can
     predict what the user will do next)

   out: (requests sent to an information publisher or a
        cache further up the food chain)



   - server, do I have latest copy of this object?

   - give me object x and the meta data for object x

   - I have a copy of object x (announcing you have a copy
     of object x to other caches or URN to URL server)

   - info publisher, what objects should I pre-fetch?
     (this assumes that the information publisher has some
     knowledge of use patterns and can predict what the user
     will do next)

   management: (commands from administrators, other
               cooperating caches, and object publishers)


   - turn parameters (e.g. consistency) on/off

   - flush the cache

   - there's a new version of object x, take it

3.3 Recommendations

   Caching and replication are important pieces of Internet middleware,
   and solutions need to be found soon. Caches and replicas have
   different performance characteristics, and there are cases where a
   combination of the two provides the best solution. There are also
   many strategies for updating and maintaining consistency of caches
   and replicated databases, and we do not believe any single
   implementation can suffice for the broad range of needs in the
   Internet.  One possible solution would be to define a general
   protocol for a replicated distributed database and for caching so
   that different information application implementations can
   interoperate and be managed via a common management interface.  A
   common protocol would provide a framework for future protocols (e.g.,
   URN2URL, DHCP) or existing protocols (e.g., Gopher or WWW) that
   presently lack a consistent solution.



McCahill, et al              Informational                      [Page 8]

RFC 1862                  IAB Workshop Report              November 1995


4. Group 2A report: Building an Information Architecture

   Karen Sollins, Abel Weinrib, Barry Leiner, Clifford Neuman, Dan
   LaLiberte, Erik Huizer, John Curran, John Klensin, Lixia Zhang,
   Michael Mealling, Mitchell Charity, Mike St. Johns, Paul Mockapetris

   This group took as its central agenda exploring an information
   architecture, the services that would instantiate such an
   architecture, and the functional interfaces between a realization of
   such an architecture and both layers on which it would sit and the
   layers that would sit on it.  In order to describe an architecture,
   one must describe not only what it includes, but also what it
   excludes.

4.1. The core model and service structure

   The general architecture has as its centerpiece objects, or as they
   are known in the Uniform Resource Identifier Working Group,
   resources.  An object in this architecture has several
   characteristics.  First, it has an identifier, assigned within the
   context of some namespace.  Such an identifier is globally unique and
   will not be reassigned to another object.  Thus, it can be said to be
   globally unique for a long time. Because such an identifier must
   remain unique for all time, it cannot contain location-relevant
   information ... locations can and will be reused. Also, since
   resources may appear in zero, one, or many locations simultaneously,
   location-dependent information can lead to a vast number of
   identifiers for an object, which will make it difficult to identify
   separately retrieved copies of an object as being the same object.
   These locations are defined by the supporting layers that provide
   transport and access. Therefore the definition of locations is not
   within the architecture, although their existence is accepted.
   Second, an object will support one or more abstract types.  Further
   determination beyond this statement was not made.  One can conclude
   from these two points that an object cannot be part of such an
   architected universe without having at least one such identifier and
   without supporting at least one type if it has at least one location.

   In addition, the architecture contains several other components.
   First, there will be a prescribed class of objects called links that
   express a relationship among other objects including the nature of
   that relationship.  It is through links that composite objects
   composed of related objects can be created and managed.  Finally,
   there is a need for several sorts of meta-information, both in order
   to discover identifiers (e.g. for indices and in support of
   searching) and to aid in the process of mapping an identifier to one
   or more potential locations.  Both of these sorts of meta-information
   are associated with objects, although they will be used and therefore



McCahill, et al              Informational                      [Page 9]

RFC 1862                  IAB Workshop Report              November 1995


   most likely managed differently, to support their distinctive access
   and update requirements.

   Given this architecture of information objects, one can identify
   several boundary points.  First, something that does not have an
   identifier or type is outside the architecture.  Second, the
   architecture does not, at this point, include any statement about
   computations, or communications paradigms other than second-handedly
   by assuming that traversal of links will occur.  Third, although
   pre-fetching, caching, and replication are important, such details
   may be hidden from higher level software components, and thus are not
   part of the data model exposed to the application in the normal case
   (though some applications may want to specify such characteristics).

   Now one can ask how such a model fits into a layered network model,
   how it might be modularized and realized.  We envisioned this
   information layer as an information "wholesale" layer.  It provides
   the general, broad model and provision of shared, network-based
   information.  Above this sit the "retailers," the marketers or
   providers of information to the marketplace of applications users.
   Below the "wholesalers" lie the providers of "raw materials."  Here
   will be the provision of supporting mechanisms and architecture from
   which information objects can come.

   The remainder of this group's report describes the modular
   decomposition of the wholesale layer, including the interactions
   among those modules, separate discussions of the interactions first
   between the retail and wholesale layers and then between the
   wholesale and raw material layers.  The report concludes with
   recommendations for where the most effective immediate efforts could
   be made to provide for the wholesale layer and make it useful.

4.2. The Wholesale Layer

   In order to realize the information architecture in the network a
   variety of classes of services or functionality must be provided.  In
   each case, there will be many instances of a sort of service,
   coordinating to a lesser or greater degree, but all within the
   general Internet model of autonomy and loose federation.  There also
   may be variants of any sort of service, to provide more specialized
   or constrained service.  In addition, services may exist that will
   provide more than one of these services, where that is deemed useful.
   Each such service will reside in one or more administrative domains
   and may be restricted or managed based on policies of those domains.
   The list of core services is described below.  Because there are many
   interdependencies, there may often be forward references in
   describing a service and its relationships to other services.




McCahill, et al              Informational                     [Page 10]

RFC 1862                  IAB Workshop Report              November 1995


   * RESOURCE DISCOVERY: Much of the activity of resource discovery,
   indexing and searching, will be in the domain of the retailers,
   although there are supporting hooks that can be provided by the
   wholesaler layer as well.  A resource discovery service will hold
   mappings from descriptions to identifiers of objects.  They will need
   to be queried.  Thus there is a general functionality for a wholesale
   layer service that answers queries formulated in certain ways and
   responds with identifiers.  The business of on what basis indices are
   computed or how they are managed will be domain specific.

   * NAMING or IDENTIFICATION: There are two aspects to assigning an
   identifier to an object, one in the wholesale layer, and one,
   arguably, in the retail layer.  In the wholesale layer, one can
   generate identifiers that are guaranteed to be unique.  In the retail
   layer one might ask the question about whether two objects are the
   same or different by the rules of an identification authority that
   therefore would determine whether they should bear the same or
   different identification from that authority.  It should be noted
   that the URI Working Group has included these two functions in the
   requirements document for URNs.

   An identification service will obviously provide functionality to the
   uniqueness authority.  It will also provide identification in the
   process of publication of objects, as will be discussed below, in the
   management of resource discovery information, object location and
   storage services, as well as cache and replication management.

   * NAME or IDENTIFICATION RESOLUTION: Since identifiers are presumed
   to be location independent, there is a need for a resolution service.
   Such a service may sometimes return other identifiers at this same
   level of abstraction (the equivalent of aliases) or location
   information, the information delivered to a transport service to
   access or retrieve an object.

   * OBJECT RETRIEVAL: Object retrieval is tightly coupled to
   resolution, because without resolution it cannot proceed.  Object
   retrieval provides the functionality of causing a representation of
   an object to be provided locally to the requester of an object
   retrieval.  This may involve the functionality of object publication
   (see below) and object storage, caching and replication services as
   well as the supporting transport facilities.