doc: Add RFC documents

1 files changed, 1795 insertions, 0 deletions

diff --git a/doc/rfc/rfc3040.txt b/doc/rfc/rfc3040.txt
new file mode 100644
index 0000000..614d07a
--- /dev/null
+++ b/doc/rfc/rfc3040.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group                                          I. Cooper
+Request for Comments: 3040                                 Equinix, Inc.
+Category: Informational                                         I. Melve
+                                                                 UNINETT
+                                                            G. Tomlinson
+                                                          CacheFlow Inc.
+                                                            January 2001
+
+
+             Internet Web Replication and Caching Taxonomy
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This memo specifies standard terminology and the taxonomy of web
+   replication and caching infrastructure as deployed today.  It
+   introduces standard concepts, and protocols used today within this
+   application domain.  Currently deployed solutions employing these
+   technologies are presented to establish a standard taxonomy.  Known
+   problems with caching proxies are covered in the document titled
+   "Known HTTP Proxy/Caching Problems", and are not part of this
+   document.  This document presents open protocols and points to
+   published material for each protocol.
+
+Table of Contents
+
+   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.      Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.1     Base Terms . . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.2     First order derivative terms . . . . . . . . . . . . . . .  6
+   2.3     Second order derivatives . . . . . . . . . . . . . . . . .  7
+   2.4     Topological terms  . . . . . . . . . . . . . . . . . . . .  7
+   2.5     Automatic use of proxies . . . . . . . . . . . . . . . . .  8
+   3.      Distributed System Relationships . . . . . . . . . . . . .  9
+   3.1     Replication Relationships  . . . . . . . . . . . . . . . .  9
+   3.1.1   Client to Replica  . . . . . . . . . . . . . . . . . . . .  9
+   3.1.2   Inter-Replica  . . . . . . . . . . . . . . . . . . . . . .  9
+   3.2     Proxy Relationships  . . . . . . . . . . . . . . . . . . . 10
+   3.2.1   Client to Non-Interception Proxy . . . . . . . . . . . . . 10
+
+
+
+Cooper, et al.               Informational                      [Page 1]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+   3.2.2   Client to Surrogate to Origin Server . . . . . . . . . . . 10
+   3.2.3   Inter-Proxy  . . . . . . . . . . . . . . . . . . . . . . . 11
+   3.2.3.1 (Caching) Proxy Meshes . . . . . . . . . . . . . . . . . . 11
+   3.2.3.2 (Caching) Proxy Arrays . . . . . . . . . . . . . . . . . . 12
+   3.2.4   Network Element to Caching Proxy . . . . . . . . . . . . . 12
+   4.      Replica Selection  . . . . . . . . . . . . . . . . . . . . 13
+   4.1     Navigation Hyperlinks  . . . . . . . . . . . . . . . . . . 13
+   4.2     Replica HTTP Redirection . . . . . . . . . . . . . . . . . 14
+   4.3     DNS Redirection  . . . . . . . . . . . . . . . . . . . . . 14
+   5.      Inter-Replica Communication  . . . . . . . . . . . . . . . 15
+   5.1     Batch Driven Replication . . . . . . . . . . . . . . . . . 15
+   5.2     Demand Driven Replication  . . . . . . . . . . . . . . . . 16
+   5.3     Synchronized Replication . . . . . . . . . . . . . . . . . 16
+   6.      User Agent to Proxy Configuration  . . . . . . . . . . . . 17
+   6.1     Manual Proxy Configuration . . . . . . . . . . . . . . . . 17
+   6.2     Proxy Auto Configuration (PAC) . . . . . . . . . . . . . . 17
+   6.3     Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 18
+   6.4     Web Proxy Auto-Discovery Protocol (WPAD) . . . . . . . . . 18
+   7.      Inter-Proxy Communication  . . . . . . . . . . . . . . . . 19
+   7.1     Loosely coupled Inter-Proxy Communication  . . . . . . . . 19
+   7.1.1   Internet Cache Protocol (ICP)  . . . . . . . . . . . . . . 19
+   7.1.2   Hyper Text Caching Protocol  . . . . . . . . . . . . . . . 20
+   7.1.3   Cache Digest . . . . . . . . . . . . . . . . . . . . . . . 21
+   7.1.4   Cache Pre-filling  . . . . . . . . . . . . . . . . . . . . 22
+   7.2     Tightly Coupled Inter-Cache Communication  . . . . . . . . 22
+   7.2.1   Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 22
+   8.      Network Element Communication  . . . . . . . . . . . . . . 23
+   8.1     Web Cache Control Protocol (WCCP)  . . . . . . . . . . . . 23
+   8.2     Network Element Control Protocol (NECP)  . . . . . . . . . 24
+   8.3     SOCKS  . . . . . . . . . . . . . . . . . . . . . . . . . . 25
+   9.      Security Considerations  . . . . . . . . . . . . . . . . . 25
+   9.1     Authentication . . . . . . . . . . . . . . . . . . . . . . 26
+   9.1.1   Man in the middle attacks  . . . . . . . . . . . . . . . . 26
+   9.1.2   Trusted third party  . . . . . . . . . . . . . . . . . . . 26
+   9.1.3   Authentication based on IP number  . . . . . . . . . . . . 26
+   9.2     Privacy  . . . . . . . . . . . . . . . . . . . . . . . . . 26
+   9.2.1   Trusted third party  . . . . . . . . . . . . . . . . . . . 26
+   9.2.2   Logs and legal implications  . . . . . . . . . . . . . . . 27
+   9.3     Service security . . . . . . . . . . . . . . . . . . . . . 27
+   9.3.1   Denial of service  . . . . . . . . . . . . . . . . . . . . 27
+   9.3.2   Replay attack  . . . . . . . . . . . . . . . . . . . . . . 27
+   9.3.3   Stupid configuration of proxies  . . . . . . . . . . . . . 28
+   9.3.4   Copyrighted transient copies . . . . . . . . . . . . . . . 28
+   9.3.5   Application level access . . . . . . . . . . . . . . . . . 28
+   10.     Acknowledgements . . . . . . . . . . . . . . . . . . . . . 28
+           References . . . . . . . . . . . . . . . . . . . . . . . . 28
+           Authors' Addresses . . . . . . . . . . . . . . . . . . . . 31
+           Full Copyright Statement . . . . . . . . . . . . . . . . . 32
+
+
+
+Cooper, et al.               Informational                      [Page 2]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+1. Introduction
+
+   Since its introduction in 1990, the World-Wide Web has evolved from a
+   simple client server model into a complex distributed architecture.
+   This evolution has been driven largely due to the scaling problems
+   associated with exponential growth.  Distinct paradigms and solutions
+   have emerged to satisfy specific requirements.  Two core
+   infrastructure components being employed to meet the demands of this
+   growth are replication and caching.  In many cases, there is a need
+   for web caches and replicated services to be able to coexist.
+
+   This memo specifies standard terminology and the taxonomy of web
+   replication and caching infrastructure deployed in the Internet
+   today.  The principal goal of this document is to establish a common
+   understanding and reference point of this application domain.
+
+   It is also expected that this document will be used in the creation
+   of a standard architectural framework for efficient, reliable, and
+   predictable service in a web which includes both replicas and caches.
+
+   Some of the protocols which this memo examines are specified only by
+   company technical white papers or work in progress documents.  Such
+   references are included to demonstrate the existence of such
+   protocols, their experimental deployment in the Internet today, or to
+   aid the reader in their understanding of this technology area.
+
+   There are many protocols, both open and proprietary, employed in web
+   replication and caching today.  A majority of the open protocols
+   include DNS [8], Cache Digests [21][10], CARP [14], HTTP [1], ICP
+   [2], PAC [12], SOCKS [7], WPAD [13], and WCCP [18][19].  These
+   protocols, and their use within the caching and replication
+   environments, are discussed below.
+
+2. Terminology
+
+   The following terminology provides definitions of common terms used
+   within the web replication and caching community.  Base terms are
+   taken, where possible, from the HTTP/1.1 specification [1] and are
+   included here for reference.  First- and second-order derivatives are
+   constructed from these base terms to help define the relationships
+   that exist within this area.
+
+   Terms that are in common usage and which are contrary to definitions
+   in RFC 2616 and this document are highlighted.
+
+
+
+
+
+
+
+Cooper, et al.               Informational                      [Page 3]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+2.1 Base Terms
+
+   The majority of these terms are taken as-is from RFC 2616 [1], and
+   are included here for reference.
+
+   client (taken from [1])
+      A program that establishes connections for the purpose of sending
+      requests.
+
+   server (taken from [1])
+      An application program that accepts connections in order to
+      service requests by sending back responses.  Any given program may
+      be capable of being both a client and a server; our use of these
+      terms refers only to the role being performed by the program for a
+      particular connection, rather than to the program's capabilities
+      in general.  Likewise, any server may act as an origin server,
+      proxy, gateway, or tunnel, switching behavior based on the nature
+      of each request.
+
+   proxy (taken from [1])
+      An intermediary program which acts as both a server and a client
+      for the purpose of making requests on behalf of other clients.
+      Requests are serviced internally or by passing them on, with
+      possible translation, to other servers.  A proxy MUST implement
+      both the client and server requirements of this specification.  A
+      "transparent proxy" is a proxy that does not modify the request or
+      response beyond what is required for proxy authentication and
+      identification.  A "non-transparent proxy" is a proxy that
+      modifies the request or response in order to provide some added
+      service to the user agent, such as group annotation services,
+      media type transformation, protocol reduction, or anonymity
+      filtering.  Except where either transparent or non-transparent
+      behavior is explicitly stated, the HTTP proxy requirements apply
+      to both types of proxies.
+
+   Note: The term "transparent proxy" refers to a semantically
+   transparent proxy as described in [1], not what is commonly
+   understood within the caching community.  We recommend that the term
+   "transparent proxy" is always prefixed to avoid confusion (e.g.,
+   "network transparent proxy").  However, see definition of
+   "interception proxy" below.
+
+   The above condition requiring implementation of both the server and
+   client requirements of HTTP/1.1 is only appropriate for a non-network
+   transparent proxy.
+
+
+
+
+
+
+Cooper, et al.               Informational                      [Page 4]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+   cache (taken from [1])
+      A program's local store of response messages and the subsystem
+      that controls its message storage, retrieval, and deletion.  A
+      cache stores cacheable responses in order to reduce the response
+      time and network bandwidth consumption on future, equivalent
+      requests.  Any client or server may include a cache, though a
+      cache cannot be used by a server that is acting as a tunnel.
+
+   Note: The term "cache" used alone often is meant as "caching proxy".
+
+   Note: There are additional motivations for caching, for example
+   reducing server load (as a further means to reduce response time).
+
+   cacheable (taken from [1])
+      A response is cacheable if a cache is allowed to store a copy of
+      the response message for use in answering subsequent requests.
+      The rules for determining the cacheability of HTTP responses are
+      defined in section 13.  Even if a resource is cacheable, there may
+      be additional constraints on whether a cache can use the cached
+      copy for a particular request.
+
+   gateway (taken from [1])
+      A server which acts as an intermediary for some other server.
+      Unlike a proxy, a gateway receives requests as if it were the
+      origin server for the requested resource; the requesting client
+      may not be aware that it is communicating with a gateway.
+
+   tunnel (taken from [1])
+      An intermediary program which is acting as a blind relay between
+      two connections.  Once active, a tunnel is not considered a party
+      to the HTTP communication, though the tunnel may have been
+      initiated by an HTTP request.  The tunnel ceases to exist when
+      both ends of the relayed connections are closed.
+
+   replication
+      "Creating and maintaining a duplicate copy of a database or file
+      system on a different computer, typically a server."  - Free
+      Online Dictionary of Computing (FOLDOC)
+
+   inbound/outbound (taken from [1])
+      Inbound and outbound refer to the request and response paths for
+      messages: "inbound" means "traveling toward the origin server",
+      and "outbound" means "traveling toward the user agent".
+
+   network element
+      A network device that introduces multiple paths between source and
+      destination, transparent to HTTP.
+
+
+
+
+Cooper, et al.               Informational                      [Page 5]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+2.2 First order derivative terms
+
+   The following terms are constructed taking the above base terms as
+   foundation.
+
+   origin server (taken from [1])
+      The server on which a given resource resides or is to be created.
+
+   user agent (taken from [1])
+      The client which initiates a request.  These are often browsers,
+      editors, spiders (web-traversing robots), or other end user tools.
+
+   caching proxy
+      A proxy with a cache, acting as a server to clients, and a client
+      to servers.
+
+      Caching proxies are often referred to as "proxy caches" or simply
+      "caches".  The term "proxy" is also frequently misused when
+      referring to caching proxies.
+
+   surrogate
+      A gateway co-located with an origin server, or at a different
+      point in the network, delegated the authority to operate on behalf
+      of, and typically working in close co-operation with, one or more
+      origin servers.  Responses are typically delivered from an
+      internal cache.
+
+      Surrogates may derive cache entries from the origin server or from
+      another of the origin server's delegates.  In some cases a
+      surrogate may tunnel such requests.
+
+      Where close co-operation between origin servers and surrogates
+      exists, this enables modifications of some protocol requirements,
+      including the Cache-Control directives in [1].  Such modifications
+      have yet to be fully specified.
+
+      Devices commonly known as "reverse proxies" and "(origin) server
+      accelerators" are both more properly defined as surrogates.
+
+   reverse proxy
+      See "surrogate".
+
+   server accelerator
+      See "surrogate".
+
+
+
+
+
+
+
+Cooper, et al.               Informational                      [Page 6]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+2.3 Second order derivatives
+
+   The following terms further build on first order derivatives:
+
+   master origin server
+      An origin server on which the definitive version of a resource
+      resides.
+
+   replica origin server
+      An origin server holding a replica of a resource, but which may
+      act as an authoritative reference for client requests.
+
+   content consumer
+      The user or system that initiates inbound requests, through use of
+      a user agent.
+
+   browser
+      A special instance of a user agent that acts as a content
+      presentation device for content consumers.
+
+2.4 Topological terms
+
+   The following definitions are added to describe caching device
+   topology:
+
+   user agent cache
+      The cache within the user agent program.
+
+   local caching proxy
+      The caching proxy to which a user agent connects.
+
+   intermediate caching proxy
+      Seen from the content consumer's view, all caches participating in
+      the caching mesh that are not the user agent's local caching
+      proxy.
+
+   cache server
+      A server to requests made by local and intermediate caching
+      proxies, but which does not act as a proxy.
+
+   cache array
+      A cluster of caching proxies, acting logically as one service and
+      partitioning the resource name space across the array.  Also known
+      as "diffused array" or "cache cluster".
+
+
+
+
+
+
+
+Cooper, et al.               Informational                      [Page 7]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+   caching mesh
+      a loosely coupled set of co-operating proxy- and (optionally)
+      caching-servers, or clusters, acting independently but sharing
+      cacheable content between themselves using inter-cache
+      communication protocols.
+
+2.5 Automatic use of proxies
+
+   Network administrators may wish to force or facilitate the use of
+   proxies by clients, enabling such configuration within the network
+   itself or within automatic systems in user agents, such that the
+   content consumer need not be aware of any such configuration issues.
+
+   The terms that describe such configurations are given below.
+
+   automatic user-agent proxy configuration
+      The technique of discovering the availability of one or more
+      proxies and the automated configuration of the user agent to use
+      them.  The use of a proxy is transparent to the content consumer
+      but not to the user agent.  The term "automatic proxy
+      configuration" is also used in this sense.
+
+   traffic interception
+      The process of using a network element to examine network traffic
+      to determine whether it should be redirected.
+
+   traffic redirection
+      Redirection of client requests from a network element performing
+      traffic interception to a proxy.  Used to deploy (caching) proxies
+      without the need to manually reconfigure individual user agents,
+      or to force the use of a proxy where such use would not otherwise
+      occur.
+
+   interception proxy (a.k.a. "transparent proxy", "transparent cache")
+      The term "transparent proxy" has been used within the caching
+      community to describe proxies used with zero configuration within
+      the user agent.  Such use is somewhat transparent to user agents.
+      Due to discrepancies with [1] (see definition of "proxy" above),
+      and objections to the use of the word "transparent", we introduce
+      the term "interception proxy" to describe proxies that receive
+      redirected traffic flows from network elements performing traffic
+      interception.
+
+      Interception proxies receive inbound traffic flows through the
+      process of traffic redirection.  (Such proxies are deployed by
+      network administrators to facilitate or require the use of
+      appropriate services offered by the proxy).  Problems associated
+      with the deployment of interception proxies are described in the
+
+
+
+Cooper, et al.               Informational                      [Page 8]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+      document "Known HTTP Proxy/Caching Problems" [23].  The use of
+      interception proxies requires zero configuration of the user agent
+      which act as though communicating directly with an origin server.
+
+3. Distributed System Relationships
+
+   This section identifies the relationships that exist in a distributed
+   replication and caching environment.  Having defined these
+   relationships, later sections describe the communication protocols
+   used in each relationship.
+
+3.1 Replication Relationships
+
+   The following sections describe relationships between clients and
+   replicas and between replicas themselves.
+
+3.1.1 Client to Replica
+
+   A client may communicate with one or more replica origin servers, as
+   well as with master origin servers.  (In the absence of replica
+   servers the client interacts directly with the origin server as is
+   the normal case.)
+
+      ------------------     -----------------     ------------------
+      | Replica Origin |     | Master Origin |     | Replica Origin |
+      |     Server     |     |    Server     |     |     Server     |
+      ------------------     -----------------     ------------------
+               \                    |                      /
+                \                   |                     /
+                 -----------------------------------------
+                                    |                 Client to
+                             -----------------        Replica Server
+                             |     Client    |
+                             -----------------
+
+   Protocols used to enable the client to use one of the replicas can be
+   found in Section 4.
+
+3.1.2 Inter-Replica
+
+   This is the relationship between master origin server(s) and replica
+   origin servers, to replicate data sets that are accessed by clients
+   in the relationship shown in Section 3.1.1.
+
+
+
+
+
+
+
+
+Cooper, et al.               Informational                      [Page 9]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+      ------------------     -----------------     ------------------
+      | Replica Origin |-----| Master Origin |-----| Replica Origin |
+      |     Server     |     |    Server     |     |     Server     |
+      ------------------     -----------------     ------------------
+
+   Protocols used in this relationship can be found in Section 5.
+
+3.2 Proxy Relationships
+
+   There are a variety of ways in which (caching) proxies and cache
+   servers communicate with each other, and with user agents.
+
+3.2.1 Client to Non-Interception Proxy
+
+   A client may communicate with zero or more proxies for some or all
+   requests.  Where the result of communication results in no proxy
+   being used, the relationship is between client and (replica) origin
+   server (see Section 3.1.1).
+
+      -----------------     -----------------     -----------------
+      |     Local     |     |     Local     |     |     Local     |
+      |     Proxy     |     |     Proxy     |     |     Proxy     |
+      -----------------     -----------------     -----------------
+               \                    |                      /
+                \                   |                     /
+                 -----------------------------------------
+                                    |
+                             -----------------
+                             |     Client    |
+                             -----------------
+
+   In addition, a user agent may interact with an additional server -
+   operated on behalf of a proxy for the purpose of automatic user agent
+   proxy configuration.
+
+   Schemes and protocols used in these relationships can be found in
+   Section 6.
+
+3.2.2 Client to Surrogate to Origin Server
+
+   A client may communicate with zero or more surrogates for requests
+   intended for one or more origin servers.  Where a surrogate is not
+   used, the client communicates directly with an origin server.  Where
+   a surrogate is used the client communicates as if with an origin
+   server.  The surrogate fulfills the request from its internal cache,
+   or acts as a gateway or tunnel to the origin server.
+
+
+
+
+
+Cooper, et al.               Informational                     [Page 10]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+            --------------  --------------   --------------
+            |   Origin   |  |   Origin   |   |   Origin   |
+            |   Server   |  |   Server   |   |   Server   |
+            --------------  --------------   --------------
+                          \        |        /
+                           \       |       /
+                           -----------------
+                           |   Surrogate   |
+                           |               |
+                           -----------------
+                                   |
+                                   |
+                             ------------
+                             |  Client  |
+                             ------------
+
+3.2.3 Inter-Proxy
+
+   Inter-Proxy relationships exist as meshes (loosely coupled) and
+   clusters (tightly coupled).
+
+3.2.3.1 (Caching) Proxy Meshes
+
+   Within a loosely coupled mesh of (caching) proxies, communication can
+   happen at the same level between peers, and with one or more parents.
+
+                        ---------------------  ---------------------
+             -----------|    Intermediate   |  |    Intermediate   |
+             |          | Caching Proxy (D) |  | Caching Proxy (E) |
+             |(peer)    ---------------------  ---------------------
+       --------------             | (parent)       / (parent)
+       |   Cache    |             |         ------/
+       | Server (C) |             |        /
+       --------------             |       /
+      (peer) |            -----------------       ---------------------
+             -------------| Local Caching |-------|    Intermediate   |
+                          |   Proxy (A)   | (peer)| Caching Proxy (B) |
+                          -----------------       ---------------------
+                                  |
+                                  |
+                              ----------
+                              | Client |
+                              ----------
+
+   Client included for illustration purposes only
+
+
+
+
+
+
+Cooper, et al.               Informational                     [Page 11]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+   An inbound request may be routed to one of a number of intermediate
+   (caching) proxies based on a determination of whether that parent is
+   better suited to resolving the request.
+
+   For example, in the above figure, Cache Server C and Intermediate
+   Caching Proxy B are peers of the Local Caching Proxy A, and may only
+   be used when the resource requested by A already exists on either B
+   or C.  Intermediate Caching Proxies D & E are parents of A, and it is
+   A's choice of which to use to resolve a particular request.
+
+   The relationship between A & B only makes sense in a caching
+   environment, while the relationships between A & D and A & E are also
+   appropriate where D or E are non-caching proxies.
+
+   Protocols used in these relationships can be found in Section 7.1.
+
+3.2.3.2 (Caching) Proxy Arrays
+
+   Where a user agent may have a relationship with a proxy, it is
+   possible that it may instead have a relationship with an array of
+   proxies arranged in a tightly coupled mesh.
+
+                              ----------------------
+                         ----------------------    |
+                     ---------------------    |    |
+                     |  (Caching) Proxy  |    |-----
+                     |      Array        |----- ^ ^
+                     --------------------- ^ ^  | |
+                         ^            ^    | |--- |
+                         |            |-----      |
+                         --------------------------
+
+   Protocols used in this relationship can be found in Section 7.2.
+
+3.2.4 Network Element to Caching Proxy
+
+   A network element performing traffic interception may choose to
+   redirect requests from a client to a specific proxy within an array.
+   (It may also choose not to redirect the traffic, in which case the
+   relationship is between client and (replica) origin server, see
+   Section 3.1.1.)
+
+
+
+
+
+
+
+
+
+
+Cooper, et al.               Informational                     [Page 12]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+      -----------------     -----------------     -----------------
+      | Caching Proxy |     | Caching Proxy |     | Caching Proxy |
+      |     Array     |     |     Array     |     |     Array     |
+      -----------------     -----------------     -----------------
+                \                   |                     /
+                 -----------------------------------------
+                                    |
+                              --------------
+                              |  Network   |
+                              |  Element   |
+                              --------------
+                                    |
+                                   ///
+                                    |
+                               ------------
+                               |  Client  |
+                               ------------
+
+   The interception proxy may be directly in-line of the flow of traffic
+   - in which case the intercepting network element and interception
+   proxy form parts of the same hardware system - or may be out-of-path,
+   requiring the intercepting network element to redirect traffic to
+   another network segment.  In this latter case, communication
+   protocols enable the intercepting network element to stop and start
+   redirecting traffic when the interception proxy becomes
+   (un)available.  Details of these protocols can be found in Section 8.
+
+4. Replica Selection
+
+   This section describes the schemes and protocols used in the
+   cooperation and communication between client and replica origin web
+   servers.  The ideal situation is to discover an optimal replica
+   origin server for clients to communicate with.  Optimality is a
+   policy based decision, often based upon proximity, but may be based
+   on other criteria such as load.
+
+4.1 Navigation Hyperlinks
+
+   Best known reference:
+      This memo.
+
+   Description:
+      The simplest of client to replica communication mechanisms.  This
+      utilizes hyperlink URIs embedded in web pages that point to the
+      individual replica origin servers.  The content consumer manually
+      selects the link of the replica origin server they wish to use.
+
+
+
+
+
+Cooper, et al.               Informational                     [Page 13]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+   Security:
+      Relies on the protocol security associated with the appropriate
+      URI scheme.
+
+   Deployment:
+      Probably the most commonly deployed client to replica
+      communication mechanism.  Ubiquitous interoperability with humans.
+
+   Submitter:
+      Document editors.
+
+4.2 Replica HTTP Redirection
+
+   Best known reference:
+      This memo.
+
+   Description:
+      A simple and commonly used mechanism to connect clients with
+      replica origin servers is to use HTTP redirection.  Clients are
+      redirected to an optimal replica origin server via the use of the
+      HTTP [1] protocol response codes, e.g., 302 "Found", or 307
+      "Temporary Redirect".  A client establishes HTTP communication
+      with one of the replica origin servers.  The initially contacted
+      replica origin server can then either choose to accept the service
+      or redirect the client again.  Refer to section 10.3 in HTTP/1.1
+      [1] for information on HTTP response codes.
+
+   Security:
+      Relies entirely upon HTTP security.
+
+   Deployment:
+      Observed at a number of large web sites.  Extent of usage in the
+      Internet is unknown.
+
+   Submitter:
+      Document editors.
+
+4.3 DNS Redirection
+
+   Best known references:
+
+      *  RFC 1794 DNS Support for Load Balancing Proximity [8]
+
+      *  This memo
+
+   Description:
+      The Domain Name Service (DNS) provides a more sophisticated client
+      to replica communication mechanism.  This is accomplished by DNS
+
+
+
+Cooper, et al.               Informational                     [Page 14]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+      servers that sort resolved IP addresses based upon quality of
+      service policies.  When a client resolves the name of an origin
+      server, the enhanced DNS server sorts the available IP addresses
+      of the replica origin servers starting with the most optimal
+      replica and ending with the least optimal replica.
+
+   Security:
+      Relies entirely upon DNS security, and other protocols that may be
+      used in determining the sort order.
+
+   Deployment:
+      Observed at a number of large web sites and large ISP web hosted
+      services.  Extent of usage in the Internet is unknown, but is
+      believed to be increasing.
+
+   Submitter:
+      Document editors.
+
+5. Inter-Replica Communication
+
+   This section describes the cooperation and communication between
+   master- and replica- origin servers.  Used in replicating data sets
+   between origin servers.
+
+5.1 Batch Driven Replication
+
+   Best known reference:
+      This memo.
+
+   Description:
+      The replica origin server to be updated initiates communication
+      with a master origin server.  The communication is established at
+      intervals based upon queued transactions which are scheduled for
+      deferred processing.  The scheduling mechanism policies vary, but
+      generally are re-occurring at a specified time.  Once
+      communication is established, data sets are copied to the
+      initiating replica origin server.
+
+   Security:
+      Relies upon the protocol being used to transfer the data set.  FTP
+      [4] and RDIST are the most common protocols observed.
+
+   Deployment:
+      Very common for synchronization of mirror sites in the Internet.
+
+   Submitter:
+      Document editors.
+
+
+
+
+Cooper, et al.               Informational                     [Page 15]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+5.2 Demand Driven Replication
+
+   Best known reference:
+      This memo.
+
+   Description:
+      Replica origin servers acquire content as needed due to client
+      demand.  When a client requests a resource that is not in the data
+      set of the replica origin server/surrogate, an attempt is made to
+      resolve the request by acquiring the resource from the master
+      origin server, returning it to the requesting client.
+
+   Security:
+      Relies upon the protocol being used to transfer the resources. FTP
+      [4], Gopher [5], HTTP [1] and ICP [2] are the most common
+      protocols observed.
+
+   Deployment:
+      Observed at several large web sites.  Extent of usage in the
+      Internet is unknown.
+
+   Submitter:
+      Document editors.
+
+5.3 Synchronized Replication
+
+   Best known reference:
+      This memo.
+
+   Description:
+      Replicated origin servers cooperate using synchronized strategies
+      and specialized replica protocols to keep the replica data sets
+      coherent.  Synchronization strategies range from tightly coherent
+      (a few minutes) to loosely coherent (a few or more hours). Updates
+      occur between replicas based upon the synchronization time
+      constraints of the coherency model employed and are generally in
+      the form of deltas only.
+
+   Security:
+      All of the known protocols utilize strong cryptographic key
+      exchange methods, which are either based upon the Kerberos shared
+      secret model or the public/private key RSA model.
+
+   Deployment:
+      Observed at a few sites, primarily at university campuses.
+
+   Submitter:
+      Document editors.
+
+
+
+Cooper, et al.               Informational                     [Page 16]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+   Note:
+      The editors are aware of at least two open source protocols - AFS
+      and CODA - as well as the proprietary NRS protocol from Novell.
+
+6. User Agent to Proxy Configuration
+
+   This section describes the configuration, cooperation and
+   communication between user agents and proxies.
+
+6.1 Manual Proxy Configuration
+
+   Best known reference:
+      This memo.
+
+   Description:
+      Each user must configure her user agent by supplying information
+      pertaining to proxied protocols and local policies.
+
+   Security:
+      The potential for doing wrong is high; each user individually sets
+      preferences.
+
+   Deployment:
+      Widely deployed, used in all current browsers.  Most browsers also
+      support additional options.
+
+   Submitter:
+      Document editors.
+
+6.2 Proxy Auto Configuration (PAC)
+
+   Best known reference:
+      "Navigator Proxy Auto-Config File Format" [12]
+
+   Description:
+      A JavaScript script retrieved from a web server is executed for
+      each URL accessed to determine the appropriate proxy (if any) to
+      be used to access the resource.  User agents must be configured to
+      request this script upon startup.  There is no bootstrap
+      mechanism, manual configuration is necessary.
+
+      Despite manual configuration, the process of proxy configuration
+      is simplified by centralizing it within a script at a single
+      location.
+
+   Security:
+      Common policy per organization possible but still requires initial
+      manual configuration.  PAC is better than "manual proxy
+
+
+
+Cooper, et al.               Informational                     [Page 17]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+      configuration" since PAC administrators may update the proxy
+      configuration without further user intervention.
+
+      Interoperability of PAC files is not high, since different
+      browsers have slightly different interpretations of the same
+      script, possibly leading to undesired effects.
+
+   Deployment:
+      Implemented in Netscape Navigator and Microsoft Internet Explorer.
+
+   Submitter:
+      Document editors.
+
+6.3 Cache Array Routing Protocol (CARP) v1.0
+
+   Best known references:
+
+      *  "Cache Array Routing Protocol" [14] (work in progress)
+
+      *  "Cache Array Routing Protocol (CARP) v1.0 Specifications" [15]
+
+      *  "Cache Array Routing Protocol and Microsoft Proxy Server 2.0"
+         [16]
+
+   Description:
+      User agents may use CARP directly as a hash function based proxy
+      selection mechanism.  They need to be configured with the location
+      of the cluster information.
+
+   Security:
+      Security considerations are not covered in the specification works
+      in progress.
+
+   Deployment:
+      Implemented in Microsoft Proxy Server, Squid.  Implemented in user
+      agents via PAC scripts.
+
+   Submitter:
+      Document editors.
+
+6.4 Web Proxy Auto-Discovery Protocol (WPAD)
+
+   Best known reference:
+      "The Web Proxy Auto-Discovery Protocol" [13] (work in progress)
+
+   Description:
+      WPAD uses a collection of pre-existing Internet resource discovery
+      mechanisms to perform web proxy auto-discovery.
+
+
+
+Cooper, et al.               Informational                     [Page 18]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+      The only goal of WPAD is to locate the PAC URL [12].  WPAD does
+      not specify which proxies will be used.  WPAD supplies the PAC
+      URL, and the PAC script then operates as defined above to choose
+      proxies per resource request.
+
+      The WPAD protocol specifies the following:
+
+      *  how to use each mechanism for the specific purpose of web proxy
+         auto-discovery
+
+      *  the order in which the mechanisms should be performed
+
+      *  the minimal set of mechanisms which must be attempted by a WPAD
+         compliant user agent
+
+      The resource discovery mechanisms utilized by WPAD are as follows:
+
+      *  Dynamic Host Configuration Protocol DHCP
+
+      *  Service Location Protocol SLP
+
+      *  "Well Known Aliases" using DNS A records
+
+      *  DNS SRV records
+
+      *  "service: URLs" in DNS TXT records
+
+   Security:
+      Relies upon DNS and HTTP security.
+
+   Deployment:
+      Implemented in some user agents and caching proxy servers.  More
+      than two independent implementations.
+
+   Submitter:
+      Josh Cohen
+
+7. Inter-Proxy Communication
+
+7.1 Loosely coupled Inter-Proxy Communication
+
+   This section describes the cooperation and communication between
+   caching proxies.
+
+7.1.1 Internet Cache Protocol (ICP)
+
+   Best known reference:
+      RFC 2186  Internet Cache Protocol (ICP), version 2 [2]
+
+
+
+Cooper, et al.               Informational                     [Page 19]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+   Description:
+      ICP is used by proxies to query other (caching) proxies about web
+      resources, to see if the requested resource is present on the
+      other system.
+
+      ICP uses UDP.  Since UDP is an uncorrected network transport
+      protocol, an estimate of network congestion and availability may
+      be calculated by ICP loss.  This rudimentary loss measurement
+      provides, together with round trip times, a load balancing method
+      for caches.
+
+   Security:
+      See RFC 2187 [3]
+
+      ICP does not convey information about HTTP headers associated with
+      resources.  HTTP headers may include access control and cache
+      directives.  Since proxies ask for the availability of resources,
+      and subsequently retrieve them using HTTP, false cache hits may
+      occur (object present in cache, but not accessible to a sibling is
+      one example).
+
+      ICP suffers from all the security problems of UDP.
+
+   Deployment:
+      Widely deployed.  Most current caching proxy implementations
+      support ICP in some form.
+
+   Submitter:
+      Document editors.
+
+   See also:
+      "Internet Cache Protocol Extension" [17] (work in progress)
+
+7.1.2 Hyper Text Caching Protocol
+
+   Best known reference:
+      RFC 2756 Hyper Text  Caching Protocol (HTCP/0.0) [9]
+
+   Description:
+      HTCP is a protocol for discovering HTTP caching proxies and cached
+      data, managing sets of HTTP caching proxies, and monitoring cache
+      activity.
+
+      HTCP requests include HTTP header material, while ICPv2 does not,
+      enabling HTCP replies to more accurately describe the behaviour
+      that would occur as a result of a subsequent HTTP request for the
+      same resource.
+
+
+
+
+Cooper, et al.               Informational                     [Page 20]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+   Security:
+      Optionally uses HMAC-MD5 [11] shared secret authentication.
+      Protocol is subject to attack if authentication is not used.
+
+   Deployment:
+      HTCP is implemented in Squid and the "Web Gateway Interceptor".
+
+   Submitter:
+      Document editors.
+
+7.1.3 Cache Digest
+
+      Best known references:
+
+      *  "Cache Digest Specification - version 5" [21]
+
+      *  "Summary Cache: A Scalable Wide-Area Web Cache Sharing
+         Protocol" [10] (see note)
+
+   Description:
+      Cache Digests are a response to the problems of latency and
+      congestion associated with previous inter-cache communication
+      mechanisms such as the Internet Cache Protocol (ICP) [2] and the
+      Hyper Text Cache Protocol [9].  Unlike these protocols, Cache
+      Digests support peering between caching proxies and cache servers
+      without a request-response exchange taking place for each inbound
+      request.  Instead, a summary of the contents in cache (the Digest)
+      is fetched by other systems that peer with it.  Using Cache
+      Digests it is possible to determine with a relatively high degree
+      of accuracy whether a given resource is cached by a particular
+      system.
+
+      Cache Digests are both an exchange protocol and a data format.
+
+      Security:
+      If the contents of a Digest are sensitive, they should be
+      protected.  Any methods which would normally be applied to secure
+      an HTTP connection can be applied to Cache Digests.
+
+      A 'Trojan horse' attack is currently possible in a mesh: System A
+      A can build a fake peer Digest for system B and serve it to B's
+      peers if requested.  This way A can direct traffic toward/from B.
+      The impact of this problem is minimized by the 'pull' model of
+      transferring Cache Digests from one system to another.
+
+
+
+
+
+
+
+Cooper, et al.               Informational                     [Page 21]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+      Cache Digests provide knowledge about peer cache content on a URL
+      level.  Hence, they do not dictate a particular level of policy
+      management and can be used to implement various policies on any
+      level (user, organization, etc.).
+
+   Deployment:
+      Cache Digests are supported in Squid.
+
+      Cache Meshes: NLANR Mesh; TF-CACHE Mesh (European Academic
+      networks
+
+   Submitter:
+      Alex Rousskov for [21], Pei Cao for [10].
+
+   Note: The technology of Summary Cache [10] is patent pending by the
+   University of Wisconsin-Madison.
+
+7.1.4 Cache Pre-filling
+
+   Best known reference:
+      "Pre-filling a cache - A satellite overview" [20] (work in
+      progress)
+
+   Description:
+      Cache pre-filling is a push-caching implementation.  It is
+      particularly well adapted to IP-multicast networks because it
+      allows preselected resources to be simultaneously inserted into
+      caches within the targeted multicast group.  Different
+      implementations of cache pre-filling already exist, especially in
+      satellite contexts.  However, there is still no standard for this
+      kind of push-caching and vendors propose solutions either based on
+      dedicated equipment or public domain caches extended with a pre-
+      filling module.
+
+   Security:
+      Relies on the inter-cache protocols being employed.
+
+   Deployment:
+      Observed in two commercial content distribution service providers.
+
+   Submitter:
+      Ivan Lovric
+
+7.2 Tightly Coupled Inter-Cache Communication
+
+7.2.1 Cache Array Routing Protocol (CARP) v1.0
+
+   Also see Section 6.3
+
+
+
+Cooper, et al.               Informational                     [Page 22]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+   Best known references:
+
+      *  "Cache Array Routing Protocol" [14] (work in progress)
+
+      *  "Cache Array Routing Protocol (CARP) v1.0 Specifications" [15]
+
+      *  "Cache Array Routing Protocol and Microsoft Proxy Server 2.0"
+         [16]
+
+   Description:
+      CARP is a hashing function for dividing URL-space among a cluster
+      of proxies.  Included in CARP is the definition of a Proxy Array
+      Membership Table, and ways to download this information.
+
+      A user agent which implements CARP v1.0 can allocate and
+      intelligently route requests for the URLs to any member of the
+      Proxy Array.  Due to the resulting sorting of requests through
+      these proxies, duplication of cache contents is eliminated and
+      global cache hit rates may be improved.
+
+   Security:
+      Security considerations are not covered in the specification works
+      in progress.
+
+   Deployment:
+      Implemented in caching proxy servers.  More than two independent
+      implementations.
+
+   Submitter:
+      Document editors.
+
+8. Network Element Communication
+
+   This section describes the cooperation and communication between
+   proxies and network elements.  Examples of such network elements
+   include routers and switches.  Generally used for deploying
+   interception proxies and/or diffused arrays.
+
+8.1 Web Cache Control Protocol (WCCP)
+
+   Best known references:
+      "Web Cache Control Protocol" [18][19] (work in progress)
+
+      Note: The name used for this protocol varies, sometimes referred
+      to as the "Web Cache Coordination Protocol", but frequently just
+      "WCCP" to avoid confusion
+
+
+
+
+
+Cooper, et al.               Informational                     [Page 23]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+   Description:
+      WCCP V1 runs between a router functioning as a redirecting network
+      element and out-of-path interception proxies.  The protocol allows
+      one or more proxies to register with a single router to receive
+      redirected traffic.  It also allows one of the proxies, the
+      designated proxy, to dictate to the router how redirected traffic
+      is distributed across the array.
+
+      WCCP V2 additionally runs between multiple routers and the
+      proxies.
+
+   Security:
+      WCCP V1 has no security features.
+      WCCP V2 provides optional authentication of protocol packets.
+
+   Deployment:
+      Network elements: WCCP is deployed on a wide range of Cisco
+      routers.
+      Caching proxies: WCCP is deployed on a number of vendors' caching
+      proxies.
+
+   Submitter:
+      David Forster
+      Document editors.
+
+8.2 Network Element Control Protocol (NECP)
+
+   Best known reference:
+      "NECP: The Network Element Control Protocol" [22] (work in
+      progress)
+
+   Description:
+      NECP provides methods for network elements to learn about server
+      capabilities, availability, and hints as to which flows can and
+      cannot be serviced.  This allows network elements to perform load
+      balancing across a farm of servers, redirection to interception
+      proxies, and cut-through of flows that cannot be served by the
+      farm.
+
+   Security:
+      Optionally uses HMAC-SHA-1 [11] shared secret authentication along
+      with complex sequence numbers to provide moderately strong
+      security.  Protocol is subject to attack if authentication is not
+      used.
+
+   Deployment:
+      Unknown at present; several network element and caching proxy
+      vendors have expressed intent to implement the protocol.
+
+
+
+Cooper, et al.               Informational                     [Page 24]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+   Submitter:
+      Gary Tomlinson
+
+8.3 SOCKS
+
+   Best known reference:
+      RFC 1928 SOCKS Protocol Version 5 [7]
+
+   Description:
+      SOCKS is primarily used as a caching proxy to firewall protocol.
+      Although firewalls don't conform to the narrowly defined network
+      element definition above, they are a integral part of the network
+      infrastructure.  When used in conjunction with a firewall, SOCKS
+      provides a authenticated tunnel between the caching proxy and the
+      firewall.
+
+   Security:
+      An extensive framework provides for multiple authentication
+      methods.  Currently, SSL, CHAP, DES, 3DES are known to be
+      available.
+
+   Deployment:
+      SOCKS is widely deployed in the Internet.
+
+   Submitter:
+      Document editors.
+
+9. Security Considerations
+
+   This document provides a taxonomy for web caching and replication.
+   Recommended practice, architecture and protocols are not described in
+   detail.
+
+   By definition, replication and caching involve the copying of
+   resources.  There are legal implications of making and keeping
+   transient or permanent copies; these are not covered here.
+
+   Information on security of each protocol referred to by this memo is
+   provided in the preceding sections, and in their accompanying
+   documentation.  HTTP security is discussed in section 15 of RFC 2616
+   [1], the HTTP/1.1 specification, and to a lesser extent in RFC 1945
+   [6], the HTTP/1.0 specification.  RFC 2616 contains security
+   considerations for HTTP proxies.
+
+
+
+
+
+
+
+
+Cooper, et al.               Informational                     [Page 25]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+   Caching proxies have the same security issues as other application
+   level proxies.  Application level proxies are not covered in these
+   security considerations.  IP number based authentication is
+   problematic when a proxy is involved in the communications.  Details
+   are not discussed here.
+
+9.1 Authentication
+
+   Requests for web resources, and responses to such requests, may be
+   directed to replicas and/or may flow through intermediate proxies.
+   The integrity of communication needs to be preserved to ensure
+   protection from both loss of access and from unintended change.
+
+9.1.1 Man in the middle attacks
+
+   HTTP proxies are men-in-the-middle, the perfect place for a man-in-
+   the-middle-attack.  A discussion of this is found in section 15 of
+   RFC 2616 [1].
+
+9.1.2 Trusted third party
+
+   A proxy must either be trusted to act on behalf of the origin server
+   and/or client, or it must act as a tunnel.  When presenting cached
+   objects to clients, the clients need to trust the caching proxy to
+   act on behalf on the origin server.
+
+   A replica may get accreditation from the origin server.
+
+9.1.3 Authentication based on IP number
+
+   Authentication based on the client's IP number is problematic when
+   connecting through a proxy, since the authenticating device only has
+   access to the proxy's IP number.  One (problematic) solution to this
+   is for the proxy to spoof the client's IP number for inbound
+   requests.
+
+   Authentication based on IP number assumes that the end-to-end
+   properties of the Internet are preserved.  This is typically not the
+   case for environments containing interception proxies.
+
+9.2 Privacy
+
+9.2.1 Trusted third party
+
+   When using a replication service, one must trust both the replica
+   origin server and the replica selection system.
+
+
+
+
+
+Cooper, et al.               Informational                     [Page 26]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+   Redirection of traffic - either by automated replica selection
+   methods, or within proxies - may introduce third parties the end user
+   and/or origin server must to trust.  In the case of interception
+   proxies, such third parties are often unknown to both end points of
+   the communication.  Unknown third parties may have security
+   implications.
+
+   Both proxies and replica selection services may have access to
+   aggregated access information.  A proxy typically knows about
+   accesses by each client using it, information that is more sensitive
+   than the information held by a single origin server.
+
+9.2.2 Logs and legal implications
+
+   Logs from proxies should be kept secure, since they provide
+   information about users and their patterns of behaviour.  A proxy's
+   log is even more sensitive than a web server log, as every request
+   from the user population goes through the proxy.  Logs from replica
+   origin servers may need to be amalgamated to get aggregated
+   statistics from a service, and transporting logs across borders may
+   have legal implications.  Log handling is restricted by law in some
+   countries.
+
+   Requirements for object security and privacy are the same in a web
+   replication and caching system as it is in the Internet at large. The
+   only reliable solution is strong cryptography.  End-to-end encryption
+   frequently makes resources uncacheable, as in the case of SSL
+   encrypted web sessions.
+
+9.3 Service security
+
+9.3.1 Denial of service
+
+   Any redirection of traffic is susceptible to denial of service
+   attacks at the redirect point, and both proxies and replica selection
+   services may redirect traffic.
+
+   By attacking a proxy, access to all servers may be denied for a large
+   set of clients.
+
+   It has been argued that introduction of an interception proxy is a
+   denial of service attack, since the end-to-end nature of the Internet
+   is destroyed without the content consumer's knowledge.
+
+9.3.2 Replay attack
+
+   A caching proxy is by definition a replay attack.
+
+
+
+
+Cooper, et al.               Informational                     [Page 27]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+9.3.3 Stupid configuration of proxies
+
+   It is quite easy to have a stupid configuration which will harm
+   service for content consumers.  This is the most common security
+   problem with proxies.
+
+9.3.4 Copyrighted transient copies
+
+   The legislative forces of the world are considering the question of
+   transient copies, like those kept in replication and caching system,
+   being legal.  The legal implications of replication and caching are
+   subject to local law.
+
+   Caching proxies need to preserve the protocol output, including
+   headers.  Replication services need to preserve the source of the
+   objects.
+
+9.3.5 Application level access
+
+   Caching proxies are application level components in the traffic flow
+   path, and may give intruders access to information that was
+   previously only available at the network level in a proxy-free world.
+   Some network level equipment may have required physical access to get
+   sensitive information.  Introduction of application level components
+   may require additional system security.
+
+10. Acknowledgements
+
+   The editors would like to thank the following for their assistance:
+   David Forster, Alex Rousskov, Josh Cohen, John Martin, John Dilley,
+   Ivan Lovric, Joe Touch, Henrik Nordstrom, Patrick McManus, Duane
+   Wessels, Wojtek Sylwestrzak, Ted Hardie, Misha Rabinovich, Larry
+   Masinter, Keith Moore, Roy Fielding, Patrik Faltstrom, Hilarie Orman,
+   Mark Nottingham and Oskar Batuner.
+
+References
+
+   [1]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
+         Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
+         HTTP/1.1", RFC 2616, June 1999.
+
+   [2]   Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP),
+         Version 2", RFC 2186, September 1997.
+
+   [3]   Wessels, D. and K. Claffy, "Application of Internet Cache
+         Protocol (ICP), Version 2", RFC 2187, September 1997.
+
+
+
+
+
+Cooper, et al.               Informational                     [Page 28]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+   [4]   Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD
+         9, RFC 959, October 1985.
+
+   [5]   Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
+         D. and B. Alberti, "The Internet Gopher Protocol", RFC 1436,
+         March 1993.
+
+   [6]   Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
+         Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
+
+   [7]   Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L.
+         Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
+
+   [8]   Brisco, T., "DNS Support for Load Balancing", RFC 1794, April
+         1995.
+
+   [9]   Vixie, P. and D. Wessels, "Hyper Text Caching Protocol
+         (HTCP/0.0)", RFC 2756, January 2000.
+
+   [10]  Fan, L., Cao, P., Almeida, J. and A. Broder, "Summary Cache: A
+         Scalable Wide-Area Web Cache Sharing Protocol", Proceedings of
+         ACM SIGCOMM'98 pp. 254-265, September 1998.
+
+   [11]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
+         for Message Authentication", RFC 2104, February 1997.
+
+   [12]  Netscape, Inc., "Navigator Proxy Auto-Config File Format",
+         March 1996,
+         <URL:http://www.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-
+         live.html>.
+
+   [13]  Gauthier, P., Cohen, J., Dunsmuir, M. and C. Perkins, "The Web
+         Proxy Auto-Discovery Protocol", Work in Progress.
+
+   [14]  Valloppillil, V. and K. Ross, "Cache Array Routing Protocol",
+         Work in Progress.
+
+   [15]  Microsoft Corporation, "Cache Array Routing Protocol (CARP)
+         v1.0 Specifications, Technical Whitepaper", August 1999,
+         <URL:http://www.microsoft.com/Proxy/Guide/carpspec.asp>.
+
+   [16]  Microsoft Corporation, "Cache Array Routing Protocol and
+         Microsoft Proxy Server 2.0, Technical White Paper", August
+         1998,
+         <URL:http://www.microsoft.com/proxy/documents/CarpWP.exe>.
+
+   [17]  Lovric, I., "Internet Cache Protocol Extension", Work in
+         Progress.
+
+
+
+Cooper, et al.               Informational                     [Page 29]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+   [18]  Cieslak, M. and D. Forster, "Cisco Web Cache Coordination
+         Protocol V1.0", Work in Progress.
+
+   [19]  Cieslak, M., Forster, D., Tiwana, G. and R. Wilson, "Cisco Web
+         Cache Coordination Protocol V2.0", Work in Progress.
+
+   [20]  Goutard, C., Lovric, I. and E. Maschio-Esposito, "Pre-filling a
+         cache - A satellite overview", Work in Progress.
+
+   [21]  Hamilton, M., Rousskov, A. and D. Wessels, "Cache Digest
+         specification - version 5", December 1998,
+         <URL:http://www.squid-cache.org/CacheDigest/cache-digest-
+         v5.txt>.
+
+   [22]  Cerpa, A., Elson, J., Beheshti, H., Chankhunthod, A., Danzig,
+         P., Jalan, R., Neerdaels, C., Shroeder, T. and G. Tomlinson,
+         "NECP: The Network Element Control Protocol", Work in Progress.
+
+   [23]  Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching Problems",
+         Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al.               Informational                     [Page 30]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+Authors' Addresses
+
+   Ian Cooper
+   Equinix, Inc.
+   2450 Bayshore Parkway
+   Mountain View, CA  94043
+   USA
+
+   Phone: +1 650 316 6065
+   EMail: icooper@equinix.com
+
+
+   Ingrid Melve
+   UNINETT
+   Tempeveien 22
+   Trondheim  N-7465
+   Norway
+
+   Phone: +47 73 55 79 07
+   EMail: Ingrid.Melve@uninett.no
+
+
+   Gary Tomlinson
+   CacheFlow Inc.
+   12034 134th Ct. NE, Suite 201
+   Redmond, WA  98052
+   USA
+
+   Phone: +1 425 820 3009
+   EMail: gary.tomlinson@cacheflow.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al.               Informational                     [Page 31]
+
+RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al.               Informational                     [Page 32]
+