Subject: taxonomy draft (8-oct-1999)

From: Ian Cooper <[email-masked]>
Date: Fri, 08 Oct 1999 19:19:31 +0100

OK folks, here's a complete copy of the current working copy of the
draft.

I'm aware that there are still issues in the terminology section.

Right now I'm a little more interested in getting some comments on
section 3.  I'd rather you pointed out issues of which I and the other
editors are aware of rather than keeping quiet: this list has been
awfully quiet of late.

Some time ago John Dilley suggested using a non-graphical method of
representing the relationships. As I've dived into this stuff over the
past few days it's become obvious that we really need this to help
lock down the relationships.  Some of the diagrams work and are easily
drawn. Others are not.  If anyone has suggestions on how we can do
this (examples definitions for 3.2.1 [including where a client may not
use any proxy] and 3.2.3 would be useful if you're not going to do all
of them) I'd be grateful.

I'd also be grateful if a proponent of surrogates would send something
to get us started in section 3.2.2

Ian

Network Working Group                                           I. Melve
Internet-Draft                                                   UNINETT
Expires: April 7, 2000                                      G. Tomlinson
                                                                  Novell
                                                               I. Cooper
                                                            Mirror Image
                                                         October 8, 1999

             Internet Web Replication and Caching Taxonomy
                      draft-ietf-wrec-taxonomy-02

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To view the entire list of Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 7, 2000.

Copyright Notice

   Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract

   This memo specifies standard terminology and the current taxonomy of
   web replication and caching infrastructure deployed today. It
   introduces standard concepts and protocols uses today within this
   application domain. Currently deployed solutions employing this
   technologies are presented to establish a standard taxonomy.
   Research issues and HTTP proxy caching known problems are covered in
   two accompanying document, and are not part of this document. This
   document presents open protocols and points to published RFCs for
   each protocol.

Melve, et. al.           Expires April 7, 2000                  [Page 1]

Internet-Draft               WREC Taxonomy                  October 1999

Table of Contents

   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  4
   2.      Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.1     Base Terms . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.2     First order derivative terms . . . . . . . . . . . . . . .  7
   2.3     Second order derivatives . . . . . . . . . . . . . . . . .  7
   2.4     Awaiting action  . . . . . . . . . . . . . . . . . . . . .  8
   2.5     Topological terms  . . . . . . . . . . . . . . . . . . . .  8
   2.6     Automatic use of proxies . . . . . . . . . . . . . . . . .  9
   3.      Distributed System Relationships . . . . . . . . . . . . . 10
   3.1     Replication Relationships  . . . . . . . . . . . . . . . . 10
   3.1.1   Client to Replica  . . . . . . . . . . . . . . . . . . . . 10
   3.1.2   Inter-Replica  . . . . . . . . . . . . . . . . . . . . . . 10
   3.2     Proxy Relationships  . . . . . . . . . . . . . . . . . . . 11
   3.2.1   Client to Non-Network Transparent Proxy  . . . . . . . . . 11
   3.2.2   Reverse Proxy to Origin Server . . . . . . . . . . . . . . 11
   3.2.3   Inter-Cache  . . . . . . . . . . . . . . . . . . . . . . . 11
   3.2.3.1 (Caching) Proxy Meshes . . . . . . . . . . . . . . . . . . 12
   3.2.3.2 (Caching) Proxy Clusters . . . . . . . . . . . . . . . . . 12
   3.2.4   Network Element to Caching Proxy . . . . . . . . . . . . . 13
   3.2.4.1 Caching Proxies with Transparency  . . . . . . . . . . . . 14
   3.2.4.2 Out-of-path Transparent Caching Proxies  . . . . . . . . . 15
   4.      Client to Replica Communication  . . . . . . . . . . . . . 16
   4.1     Navigation Hyperlinks  . . . . . . . . . . . . . . . . . . 16
   4.2     URL Redirection  . . . . . . . . . . . . . . . . . . . . . 16
   4.3     DNS Redirection  . . . . . . . . . . . . . . . . . . . . . 17
   5.      Inter-Replica Communication  . . . . . . . . . . . . . . . 18
   5.1     Batch Driven Mirror Replication  . . . . . . . . . . . . . 18
   5.2     Demand Driven Mirror Replication . . . . . . . . . . . . . 18
   5.3     Synchronized Replication . . . . . . . . . . . . . . . . . 19
   6.      Client to Proxy Configuration  . . . . . . . . . . . . . . 20
   6.1     Manual Proxy Configuration . . . . . . . . . . . . . . . . 20
   6.2     Proxy Auto Configuration (PAC) . . . . . . . . . . . . . . 20
   6.3     Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 21
   6.4     Web Proxy Auto-Discovery Protocol (WPAD) . . . . . . . . . 21
   7.      Inter-Cache Communication  . . . . . . . . . . . . . . . . 23
   7.1     Loosely coupled Inter-Cache Communication  . . . . . . . . 23
   7.1.1   Internet Cache Protocol (ICP)  . . . . . . . . . . . . . . 23
   7.1.2   Hyper Text Caching Protocol (HTCP/0.0) . . . . . . . . . . 23
   7.1.3   Cache Digest . . . . . . . . . . . . . . . . . . . . . . . 24
   7.1.4   Cache Pre-filling  . . . . . . . . . . . . . . . . . . . . 25
   7.2     Tightly Coupled Inter-Cache Communication  . . . . . . . . 26
   7.2.1   Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 26
   8.      Network Element Communication  . . . . . . . . . . . . . . 27
   8.1     Web Cache Coordination Protocol (WCCP) . . . . . . . . . . 27
   8.2     Transparent Proxy Agent Control Protocol (TPACT) . . . . . 27
   8.3     SOCKS  . . . . . . . . . . . . . . . . . . . . . . . . . . 28
   9.      Security Considerations  . . . . . . . . . . . . . . . . . 29

Melve, et. al.           Expires April 7, 2000                  [Page 2]

Internet-Draft               WREC Taxonomy                  October 1999

   9.1     Authentication . . . . . . . . . . . . . . . . . . . . . . 29
   9.1.1   Man in the middle attacks  . . . . . . . . . . . . . . . . 29
   9.1.2   Trusted third party  . . . . . . . . . . . . . . . . . . . 29
   9.1.3   Authentication based on IP number  . . . . . . . . . . . . 30
   9.2     Privacy  . . . . . . . . . . . . . . . . . . . . . . . . . 30
   9.2.1   Trusted third party  . . . . . . . . . . . . . . . . . . . 30
   9.2.2   Logs and legal implications  . . . . . . . . . . . . . . . 30
   9.3     Service security . . . . . . . . . . . . . . . . . . . . . 31
   9.3.1   Denial of service  . . . . . . . . . . . . . . . . . . . . 31
   9.3.2   Replay attack  . . . . . . . . . . . . . . . . . . . . . . 31
   9.3.3   Stupid configuration of proxies  . . . . . . . . . . . . . 31
   9.3.4   Copyrighted transient copies . . . . . . . . . . . . . . . 31
   9.3.5   Application level access . . . . . . . . . . . . . . . . . 31
   10.     Acknowledgements . . . . . . . . . . . . . . . . . . . . . 32
           References . . . . . . . . . . . . . . . . . . . . . . . . 33
           Authors' Addresses . . . . . . . . . . . . . . . . . . . . 34
           Full Copyright Statement . . . . . . . . . . . . . . . . . 36

Melve, et. al.           Expires April 7, 2000                  [Page 3]

Internet-Draft               WREC Taxonomy                  October 1999

1. Introduction

   Since its introduction in 1990, the World-Wide Web has evolved from
   a simple client server model into a sophisticated 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 infrastructural components being employed to
   meet the demands of this growth are replication and caching. In man
   cases, there is a need for web caches and replicated services to be
   able to coexist.

   There are many protocols, both open and proprietary, employed in web
   replication and caching today.  A majority of the open protocols
   include DNS[19], CacheDigest[22], CARP[9], HTTP[6], ICP[10], PAC[7],
   SOCKS[17], TPACT[20], WPAD[8], and WCCP[16]. Additional protocols
   are being planned to address emerging solution requirements.

   This memo specifies standard terminology and the current 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.

   We also expect 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.

Melve, et. al.           Expires April 7, 2000                  [Page 4]

Internet-Draft               WREC Taxonomy                  October 1999

2. Terminology

   The following terminology provides definitions of common terms used
   within the IETF WREC working group documents. Base terms are taken,
   where possible, from [5][6] and are included here for reference. 
   From these base terms we describe first- and second-order
   derivatives as well as terms that describe common structural
   language used within the community.

   We highlight those terms that have become used colloquially to mean
   something other than the definitions given in this document, and
   strongly caution against such colloquial use in the future.

2.1 Base Terms

   The majority of these terms are taken as-is from RFC 2616[6], and
   are included here for reference. 

   client (as given in [6])
      A program that establishes connections for the purpose of sending
      requests.

   server (as given in [6])
      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 (as given in [6])
      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

Melve, et. al.           Expires April 7, 2000                  [Page 5]

Internet-Draft               WREC Taxonomy                  October 1999

   transparent proxy as described in [6], 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").

   The above condition requiring implementation of both the server and
   client requirements of HTTP/1.1 is only appropriate for a
   non-transparent proxy.

   cache (as given in [6])
      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".

   Ed.Note;IAN: This is the actual definition from RFC2616, but now
      excludes consideration of a reduction in server load. Do we wish
      to comment on that, is is response time related to server load in
      such a way that the comment is unnecessary?

   cacheable (as given in [6])
      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.

   tunnel (as given in [6])
      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.

   Ed.Note;IAN: Should consider comments from Joe Touch on whether we
   should distinguish types of tunnels

   replica [ TBC ]

   replication [ TBC ]

   inbound/outbound (as given in [6])
      Inbound and outbound refer to the request and response paths for
      messages: "inbound" means "traveling toward the origin server",

Melve, et. al.           Expires April 7, 2000                  [Page 6]

Internet-Draft               WREC Taxonomy                  October 1999

      and "outbound" means "traveling toward the user agent"

2.2 First order derivative terms

   The following terms are constructed taking the above base terms as
   foundation. 

   origin server (as given in [6])
      The server on which a given resource resides or is to be created.

   user agent (as given in [6])
      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

      The following colloquial terms are also used to refer to caching
      proxies: 

      *  proxy

      *  cache

   surrogate (a.k.a. "reverse proxies", "server accelerators")
      An intermediary program which acts as a server or tunnel for the
      purpose of responding to requests on behalf of one or more origin
      servers. Requests are serviced internally from a cache or by
      tunneling them on to origin servers. The implementation
      requirements for surrogates have not been standardized; depending
      on the implementation, surrogates may or may not respond to the
      cache directives defined in [6]. Surrogates are also known as
      "reverse proxies" and "(origin) server accelerators".

   replica origin server / mirror [ TBC ]

2.3 Second order derivatives

   The following terms further build on first order derivatives 

   authoritative reference 
      The owner of data; content production system; possibly an origin
      server; the overall master copy of the content, if any

   content consumer 
      The user or system that initiates requests of an origin server
      (which may in turn be handled by a proxy).

   browser 

Melve, et. al.           Expires April 7, 2000                  [Page 7]

Internet-Draft               WREC Taxonomy                  October 1999

      A special instance of a user agent that acts as a content
      presentation device for content consumers.

2.4 Awaiting action

   A placeholder for terms that need to be considered/deleted/moved 

   network element 
      A network device that introduces multiple paths between source
      and destination, transparent to HTTP.
      [Ed note; IAN: This term probably needs a better name.]

2.5 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 a user agent connects to [Ed note; IAN: should
      this be renamed 'primary proxy'?]

   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 URL name space across the array. Also known as: 

      *  diffused array

      *  cache cluster

   caching mesh 
      a loosely coupled set of co-operating proxy- or caching- servers,
      or clusters, acting independently but sharing cacheable content
      between themselves using inter-cache communication protocols (see
      Section 7)

Melve, et. al.           Expires April 7, 2000                  [Page 8]

Internet-Draft               WREC Taxonomy                  October 1999

2.6 Automatic use of proxies

   Moves to insert proxies into the network in a manner such at the
   content consumer is unaware of their presence has created a set of
   terms whose definitions may not be consistent with other uses.  This
   section references prior definitions but also gives their meaning in
   the realm of Web caching.

   proxy discovery 
      The discovery and configuration for use of a proxy in an
      environment where the content consumer may be unaware of the
      proxy's existence.  The use of the proxy is transparent to the
      content consumer, but not to the client.

   [Ed note; IAN: should we consider the ability of proxies to discover
   each other?  Would this be better titled as "transparent proxy
   configuration"?

   traffic interception 
      The process of using a network element to examine network traffic
      to determine whether it should be redirected

   traffic redirection 
      Redirection of traffic from a user agent or network element to a
      specific proxy, following its interception. Used to deploy
      Web-caching without the need to manually reconfigure individual
      user agents, or to force the use of a proxy where such use would
      not otherwise occur

   (network) transparent proxy 
      A proxy that receives traffic as a result of network traffic
      redirection. The term "transparent proxy" is typically used to
      refer to a network transparent proxy and the additional systems
      that perform traffic redirection. The use of this type of proxy
      is transparent to the client.  Due to a conflicting definition in
      [6], caution should be exercised when referring to a "transparent
      proxy". As stated above, it is recommended that the phrase
      "transparent proxy" is prepended with appropriate terminology to
      avoide confusion.

Melve, et. al.           Expires April 7, 2000                  [Page 9]

Internet-Draft               WREC Taxonomy                  October 1999

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

   [Ed note; describe the replication system relationship domain]

3.1.1 Client to Replica

   A client may communicate with one or more replica origin servers, as
   well as with master origin servers (or in a non-replicated
   environment directly with the origin server).

                       Persistent Domain
                         Complete Idem-Potent Set Replication
       ------------------     -----------------     ------------------
       | Replica Origin |     | Master Origin |     | Replica Origin |
       |     Server     |     |    Server     |     |     Server     |
       ------------------     -----------------     ------------------
                \                    |                      /
                 \                   |                     /
                  -----------------------------------------
                                     |                 Client to
                              -----------------        Replica Server
                              |     Client    |
                              |               |
                              -----------------

   Protocols used in this relationship can be found in Section 4.

3.1.2 Inter-Replica

   This is the relationship between master origin server(s)
   ["authoritative reference"] and replica origin servers, to replicate
   data sets that are accessed by clients as shown in Section 3.1.1.

                      Persistent Domain
                         Complete Idem-Potent Set Replication
       ------------------     -----------------     ------------------
       | Replica Origin |-----| Master Origin |-----| Replica Origin |
       |     Server     |     |    Server     |     |     Server     |
       ------------------     -----------------     ------------------

Melve, et. al.           Expires April 7, 2000                 [Page 10]

Internet-Draft               WREC Taxonomy                  October 1999

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

3.2.1 Client to Non-Network Transparent 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 cache and origin server or
   replica origin server (see Section 3.1.1).

                           Temporal Domain
                             Sparse Working Set Cache
       -----------------     -----------------     -----------------
       |     Local     |     |     Local     |     |     Local     |
       |     Proxy     |     |     Proxy     |     |     Proxy     |
       -----------------     -----------------     -----------------
                \                    |                      /
                 \                   |                     /
                  -----------------------------------------
                                     |
                              -----------------
                              |     Client    |
                              -----------------

   Protocols used in this relationship can be found in Section 6.

3.2.2 Reverse Proxy to Origin Server

   [Ed note; describe the accelerator relationship]

   [Ed note; needs to be recast as relationship between surrogate and
   origin server]

3.2.3 Inter-Cache

   [Ed note; recast this as relationship not the definition which
   follows in section 7] Inter-Cache: cooperation and communication
   between caching proxies.

   Inter-(caching)Proxy relationships exist in loosely coupled (mesh)
   relationships, and tightly coupled (cluster) relationships.

Melve, et. al.           Expires April 7, 2000                 [Page 11]

Internet-Draft               WREC Taxonomy                  October 1999

3.2.3.1 (Caching) Proxy Meshes

   Within a loosely coupled mesh of (caching) proxies, communication
   can happen at the same level, between siblings, and with one or more
   parents.

   [Ed note; Diagram needs updating]

                           Temporal Domain
                             Sparse Working Set Cache
                              -----------------
                              |   Top-Level   |
                              | Caching Proxy |
                              -----------------
                                /            \
                               /              \
                 -----------------           -----------------
                 |  Upper-Level  |-----------|  Upper-Level  |
                 | Caching Proxy |           | Caching Proxy |
                 -----------------           -----------------
                        / \                    /    \
                       /   \                  /      \
                      /     \                /        \
                     /       \              /          \
                    /         \            /            \
                   /           \          /              \
       -----------------     -----------------       -----------------
       |  First Level  |-----|  First Level  |-------|  First Level  |
       | Caching Proxy |     | Caching Proxy |       | Caching Proxy |
       -----------------     -----------------       -----------------

   An outbound request from a local (caching) proxy 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.

   Protocols used in this relationship can be found in Section 7.1.

3.2.3.2 (Caching) Proxy Clusters

   [Ed note; is this really an inter-cache relationship?]

Melve, et. al.           Expires April 7, 2000                 [Page 12]

Internet-Draft               WREC Taxonomy                  October 1999

                                     +--------------------+
   	    	             +--------------------+    |
                            +-------------------+    |    |
                            |  (Caching) Proxy  |    |----+
          	       	       	 |    	Array        |----+ ^ ^
          	       	         +-------------------+ ^ ^  | |
                                ^	       	  ^    | |--+ |
                                |            +----+      |
                                +------------------------+

   Protocols used in this relationship can be found in Section 7.2.

3.2.4 Network Element to Caching Proxy

   [Ed note; recast this as relationship not the definition which
   follows in section 8] Network Element to Proxy Cache: cooperation
   and communication between caching proxy and network elements. 
   Examples include routes and switches.  Generally used for
   transparent caching and/or diffused arrays.

   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 origin server or replica origin
   server, see Section 3.1.1.)

Melve, et. al.           Expires April 7, 2000                 [Page 13]

Internet-Draft               WREC Taxonomy                  October 1999

   [Ed note; Should this diagram be re-drawn to show a proper "array"?]

                           Temporal Domain
                             Sparse Working Set Cache
       -----------------     -----------------     -----------------
       | Caching Proxy |     | Caching Proxy |     | Caching Proxy |
       |     Array     |     |     Array     |     |     Array     |
       -----------------     -----------------     -----------------
                \                    |                      /
                 \                   |                     /
                  -----------------------------------------
                                     |
                                --------------
                                |  Network   |
                                |  Element   |
                                --------------
                                     |
                                     |
                                 ------------
                                 |  Client  |
                                 ------------

   Protocols used in this relationship can be found in Section 8.

3.2.4.1 Caching Proxies with Transparency

   [Ed note: Currently contains citations from NetApp document, need
   rewording to avoid specific products and concentrate on generic
   properties. Explain network elements and NATs and other ways
   interception may happen. Intro to usage and "normal" setup.]

   Reference [1][2][3][4] for introduction to caching proxies with
   transparency.

   The goal of intercepting web traffic is to provide a transparent web
   proxy, thus avoiding the hassle of individually configuring each
   client.

   Transparency means that the user does not need to be aware of the
   proxy.

   The origin server see connections coming from the proxy, not from
   the individual end user. Authentication based on client IP address
   do not work if there is a transparent proxy cache in the way to the
   web server.

   A web cache is said to be transparent if clients can access the
   cache without the need to configure their browsers, using either a

Melve, et. al.           Expires April 7, 2000                 [Page 14]

Internet-Draft               WREC Taxonomy                  October 1999

   proxy auto-configuration URL or a manual proxy setting. Transparent
   caches appear as a seamless part of the network infrastructure,
   rather than a set of discrete proxy servers, and function much like
   a transparent firewall. Many ISPs and carriers desire transparent
   caches because it lets them retrofit their network with caching
   without action at the client. However, when deployed transparently,
   a web cache must be as fail-safe and scalable as the rest of the
   network. [2]

   A transparent cache acts much like a gateway or firewall -- it
   effectively sits between the users and the network. The advantage of
   transparent caching is that it eliminates the need to configure
   browsers to use caching. Another strength (and sometimes a weakness)
   is that it is impossible to bypass caching. [2]

   Conceptually, transparency works by modifying the TCP/IP stack of a
   cache so that it operates in "promiscuous mode" and effectively
   binds itself to all possible IP addresses. [2]

   We need to give a far more abstract definition which includes the
   way that router and switch redirection, and within-router action,
   operate.

   Comment on some of the problems: 

   o  limited number of ports which can be captured

   o  due to "unexpected" data on other ports (or even on well known
      ports), as experienced by setting up various services on port 80

   o  well known problems with use of HTTP for transport[18]

3.2.4.2 Out-of-path Transparent Caching Proxies

   An Out-of-path Transparent Caching Proxy performs the same proxy and
   caching functions as a Transparent Caching Proxy and is similarly
   transparent to the client. However it does not lie on the forwarding
   path between a client and a server and does not perform web traffic
   interception. Instead it relies upon a redirecting network element
   in the path between client and server to intercept and redirect web
   traffic to it. One advantage of this method of transparent caching
   is that in the case of cache failure the network element can,
   providing it monitors the state of the caches, revert to forwarding
   web traffic direct to the server. It is also possible for the
   network element to distribute the web traffic load across a group of
   caches. This method of transparent caching generally requires a
   protocol to be run between the redirecting network element and the
   cache or caches.

Melve, et. al.           Expires April 7, 2000                 [Page 15]

Internet-Draft               WREC Taxonomy                  October 1999

4. Client to Replica Communication

   This section describes the cooperation and communication between
   clients (both user agents and proxy caches) and replica origin web
   servers.  Used to discover a optimal web origin server replica for a
   web client to establish service 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

   Authoritative reference: 
      This memo.

   Description: 
      The simplest of client to replica communication mechanisms.  This
      utilizes hyperlink URLs embedded in web pages that point to the
      mirror sites.  The human user manually selects the link of the
      replica origin server they wish to use.

   Security: 
      Relies on the protocol security associated with the URL scheme.

   Deployment: 
      Probably the most commonly deployed client to replica
      communication mechanism.  Ubiquitous interoperability with humans.

   Submitter: 
      Document editors.

4.2 URL Redirection

   Authoritative reference: 
      This memo.

   Description: 
      A simple and commonly used mechanism to connect web clients with
      origin server replicas is to use URL redirection.  Clients are
      redirected to a optimal web server replica via the use of the
      HTTP[6] protocol response code 307 Temporary Redirect. A web
      client establishes HTTP communication with one of the web server
      replicas.  The initially contacted replica origin web server can
      either choose to accept the service or redirect the client to the
      proper replica. Refer to section 10.3.8 in HTTP/1.1 RFC2616 for
      information on HTTP response code 307.

   Security: 
      Relies entirely upon HTTP security.

Melve, et. al.           Expires April 7, 2000                 [Page 16]

Internet-Draft               WREC Taxonomy                  October 1999

   Deployment: 
      Observed at a number of large web sites.  Extent of usage in the
      Internet is unknown at this time.

   Submitter: 
      Document editors.

   [Ed note; Is this too specific for describing what Akamai etc.
   currently do?]

4.3 DNS Redirection

   [Ed note;  it would have been nice to cite SONAR, but draft has
   expired] 

   Authoritative reference: 
      Load balancing: RFC1794 DNS Support for Load Balancing
      Proximity[19]: This memo

   Description: 
      The Domain Name Service (DNS) provides a more sophisticated
      client to replica communication mechanism.  This is accomplished
      by DNS servers that implement order of addresses based upon
      quality of service policies. When a web client resolves the name
      of a web server, the enhanced DNS server orders the IP addresses
      of the web server starting with the most optimal replica and
      ending with the least optimal replica.

   Security: 
      Relies entirely upon DNS security.

   Deployment: 
      Observed at a number of large web sites and large ISP web hosted
      services.  Extent of usage in the Internet is unknown at this
      time.

   Submitter: 
      Document editors.

Melve, et. al.           Expires April 7, 2000                 [Page 17]

Internet-Draft               WREC Taxonomy                  October 1999

5. Inter-Replica Communication

   This section describes the cooperation and communication between
   replica origin servers.  Used in replicating data sets between
   origin servers.

5.1 Batch Driven Mirror Replication

   Authoritative reference: 
      This memo.

   Description: 
      In this model, the replica web server to be updated initiates
      communication with a master origin web 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 reoccuring at a specified time. 
      Once communication is established, data sets are copied to the
      initiating replica web server.

   Security: 
      Relies upon the protocol being used to transfer the data set. FTP
      and RDIST are the most common protocols observed.

   Deployment: 
      Very common for mirror synchronization in the Internet.

   Submitter: 
      Document editors.

5.2 Demand Driven Mirror Replication

   Authoritative reference: 
      This memo.

   Description: 
      In this model, the replica web server acquires the content as
      needed due to demand.  This is generally done by web server
      accelerators (reverse proxy) operating as origin server replicas.
      When a web client requests a URL that is not in the data set or
      the replica origin server, the replica server attempts to acquire
      it from a master origin server and forwarded on to the requesting
      web client.

   Security: 
      Relies upon the protocol being used to transfer the URLs.  FTP,
      Gopher, HTTP and ICP are the most common protocols observed.

   Deployment: 

Melve, et. al.           Expires April 7, 2000                 [Page 18]

Internet-Draft               WREC Taxonomy                  October 1999

      Observed at several large web sites. Extent of usage in the
      Internet is unknown at this time.

   Submitter: 
      Document editors.

5.3 Synchronized Replication

   Authoritative reference: 
      This memo.

      Ed note: there is no IETF protocol specified at this time. The
         editors are aware of at least two open source protocols, AFS
         and CODA, along with one expired IETF draft
         <draft-leach-cifs-v1-spec-01.txt> and one proprietary protocol
         Novell NRS; none of which can be considered an authoritative
         reference

   Description: 
      In this model, the 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.

Melve, et. al.           Expires April 7, 2000                 [Page 19]

Internet-Draft               WREC Taxonomy                  October 1999

6. Client to Proxy Configuration

   This section describes the configuration, cooperation and
   communication between end user clients (browsers and applications) a
   proxy.

6.1 Manual Proxy Configuration

   Authoritative reference: 
      This memo.

   Description: 
      Each user needs to configure its web client by typing in
      information pertaining to proxied protocols and local policies.

   Security: 
      The potential for doing wrong is high, as each user individually
      sets preferences.

   Deployment: 
      Widely deployed, used in all current browsers. Most browsers
      support other options as well.

   Submitter: 
      Document editors.

6.2 Proxy Auto Configuration (PAC)

   [Ed note: Does it really need to be submitted for Informational RFC?]

   Authoritative reference: 
      No RFC published, no Internet-Draft Navigator Proxy Auto-Config
      File Format[7]. Available from
      http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html[24]

   Description: 
      A JavaScript page on a web server hands out information on where
      to find proxies. Clients need to point at the URL of this page.
      No bootstrap mechanism, manual configuration necessary.

      Manual configuration is made easier by centralizing the script to
      one URL.

   Security: 
      Common policy per organization possible. Does still require
      manual configuration. PAC is better than "manual proxy
      configuration" because with PAC administrators can update the
      proxy configuration without user intervention.

      Interoperability of PAC files is not as good as wanted, since
      more popular browsers have slightly different interpretation of

Melve, et. al.           Expires April 7, 2000                 [Page 20]

Internet-Draft               WREC Taxonomy                  October 1999

      the script, and this may lead to undesired effects.

   Deployment: 
      Implemented in most web clients.

   Submitter: 
      Document editors.

6.3 Cache Array Routing Protocol (CARP) v1.0

   [Ed note: Current draft expired. A new draft must submitted and this
   section completed for this protocol to be considered in the Taxonomy]

   Authoritative reference: 
      Expired Internet-Draft draft-vinod-carp-v1-03.txt Work in
      progress.

   Description: 
      Clients 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: 

   Deployment: 

   Submitter: 

6.4 Web Proxy Auto-Discovery Protocol (WPAD)

   Authoritative reference: 
      Internet Draft <draft-ietf-wrec-wpad-00.txt> [Ed note; I-D
      submission anticipated by 6/25/99] Work in progress.

   Description: 
      WPAD uses a collection of pre-existing Internet resource
      discovery mechanisms to perform web proxy auto-discovery.

      The only goal of WPAD is to locate the PAC URL. WPAD does not
      specify which proxies will be used. WPAD gets you to the PAC URL,
      and the PAC script chooses the proxies for you.

      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 web client

Melve, et. al.           Expires April 7, 2000                 [Page 21]

Internet-Draft               WREC Taxonomy                  October 1999

      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 web clients and caching proxy servers. More than
      two independent implementations.

   Submitter: 
      Josh Cohen, Microsoft, [email-masked]

Melve, et. al.           Expires April 7, 2000                 [Page 22]

Internet-Draft               WREC Taxonomy                  October 1999

7. Inter-Cache Communication

   [Ed note: INGRID.  Review and chase submissions (push Duane)]

7.1 Loosely coupled Inter-Cache Communication

   This section describes the cooperation and communication between
   caching proxies.

7.1.1 Internet Cache Protocol (ICP)

   See [10][11][12][13][14]

   Authoritative reference: 
      RFC 2186 Internet Cache Protocol (ICP), version 2

   Description: 
      ICP is used by caches to query other caches about web objects, to
      see if a web object is present at the other cache.

      ICP uses UDP. Since UDP is unreliable, an estimate of network
      congestion and availability may be calculated by ICP loss. This
      rudimentary loss measurement does, together with round trip times
      provide a load balancing method for caches.

   Security: 
      ICP does not convey information about HTTP headers associated
      with a web object. HTTP headers may include access control and
      cache directives, Since caches ask for objects, and then download
      the objects using HTTP, false cache hits may occur (object
      present in cache, but not accessible for sibling cache is one
      example).

      ICP suffer from all the security problems of UDP.

   Deployment: 
      Widely deployed. Most current cache implementations support ICP
      in one form or the other.

   Submitter: 
      Document editors.

7.1.2 Hyper Text Caching Protocol (HTCP/0.0)

   See [23]

   [Ed note: Based upon reviewers comments, the editors would like to
   drop this protocol from current Taxonomy consideration, due to its
   experimental nature]

   Authoritative reference: 

Melve, et. al.           Expires April 7, 2000                 [Page 23]

Internet-Draft               WREC Taxonomy                  October 1999

      Internet Draft draft-vixie-htcp-proto-05.txt, Work in Progress

   Description: 
      HTCP is a protocol for discovering HTTP caches and cached data,
      managing sets of HTTP caches, and monitoring cache activity.

      HTCP includes HTTP headers, while ICPv2 does not. HTTP headers
      are vital information for web proxy caches.

   Security: 
      Optionally uses the MD5 shared secret authentication. Lack of
      authentication option make protocol subject to attack.

   Deployment: 
      Implemented in caching proxies (two independent implementations)

   Submitter: 
      Document editors.

7.1.3 Cache Digest

   See [22]

   [Ed note: Does it really need to be submitted for Informational RFC?]

   Authoritative reference: 
      No RFC published, no Internet-Draft Cache Digest specification
      http://squid.nlanr.net/Squid/CacheDigest/ cache-digest-v5.txt
      Squid Digest FAQ entry
      http://squid.nlanr.net/Squid/FAQ/FAQ-16.html

   Description: 
      Cache Digests are a response to the problems of latency and
      congestion associated with previous inter-cache communications
      mechanisms such as the Internet Cache Protocol (ICP) [10][11] and
      the HyperText Cache Protocol[23]. Unlike most of these protocols,
      Cache Digests support peering between cache servers without a
      request-response exchange taking place. Instead, a summary of the
      contents of the server (the Digest) is fetched by other servers
      which peer with it. Using Cache Digests it is possible to
      determine with a relatively high degree of accuracy whether a
      given URL is cached by a particular server.

      Cache Digests are both an exchange protocol and a data format
      [22].

   Security: 
      If the contents of a Digest is sensitive, it should be protected
      from access by The Wrong People. Any methods which would normally
      be applied to secure an HTTP connection can be applied to Cache
      Digests.

Melve, et. al.           Expires April 7, 2000                 [Page 24]


Internet-Draft               WREC Taxonomy                  October 1999

      A 'Trojan horse' attack is currently possible in a cache mesh:
      Cache A can build a fake peer Digest for cache 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 server to another.

      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; several commercial vendors
      are looking into Digest support.

      Cache Meshes:

      *  NLANR Mesh

      *  TF-CACHE mesh (European Academic networks)

   Submitter: 
      Alex Rousskov, NLANR, [email-masked]

7.1.4 Cache Pre-filling

   See [21]

   Authoritative reference: 
      Internet Draft <draft-lovric-francetelecom-satellites-00.txt>
      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 URLs to be inserted in one single time within
      all the caches that belong to 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 equipments 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, France Telecom, [email-masked]

Melve, et. al.           Expires April 7, 2000                 [Page 25]

Internet-Draft               WREC Taxonomy                  October 1999

7.2 Tightly Coupled Inter-Cache Communication

7.2.1 Cache Array Routing Protocol (CARP) v1.0

   [9]

   [Ed note: Current draft expired. A new draft must submitted and this
   section completed for this protocol to be considered in the Taxonomy]

   Authoritative reference: 
      Work in Progress: Internet-Draft draft-vinod-carp-v1-03.txt

   Description: 
      CARP is a hashing function for dividing URL-space among a cluster
      of proxy caches. Included in CARP is the definition of a Proxy
      Array Membership Table, and ways to download this information.

      An HTTP client agent (either a proxy server or a client browser)
      which implements CARP v1.0 can allocate and intelligently route
      requests for the correct 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: 

   Deployment: 
      Implemented in caching proxy servers. More than two independent
      implementations.

   Submitter: 

Melve, et. al.           Expires April 7, 2000                 [Page 26]

Internet-Draft               WREC Taxonomy                  October 1999

8. Network Element Communication

   This section describes the cooperation and communication between
   caching proxy and network elements.  Examples include routers and
   switches.  Generally used for transparent caching and/or diffused
   arrays.

8.1 Web Cache Coordination Protocol (WCCP)

   Authoritative reference: 
      Internet Draft <draft-ietf-wrec-web-pro-00.txt> [16] Work in
      progress.

   Description: 
      WCCP V1 runs between a router functioning as a redirecting
      network element and out-of-path transparent caching proxies. The
      protocol allows one or more caching proxies to register
      themselves with a single router to receive redirected web
      traffic. It also allows one of the proxies, the designated proxy,
      to dictate to the router how redirected web traffic is
      distributed across the caching proxies.

   Security: 
      WCCP V1 has no security features.

   Deployment: 
      Network elements: WCCP V1 is deployed on a wide range of Cisco
      routers.
      Caching proxies: WCCP V1 is deployed on a number of vendors'
      caches.

   Submitter: 
      David Forster, CISCO, [email-masked]

8.2 Transparent Proxy Agent Control Protocol (TPACT)

   Authoritative reference: [Ed note; anticipated submission] 
      Internet Draft <draft-ietf-wrec-tpact-00.txt> [20] [Ed note; I-D
      submission anticipated by 6/25/99] Work in progress.

   Description: 
      TPACT runs between a network elements (router or switch)
      functioning as a redirecting network element and out-of-path
      transparent caching proxies. The protocol allows one or more
      caching proxies to register themselves with a single network
      element to receive redirected web traffic. All of the
      participating caching proxies operate as a quorum in the
      diectating of web traffic distribution across the group.

Melve, et. al.           Expires April 7, 2000                 [Page 27]

Internet-Draft               WREC Taxonomy                  October 1999

   Security: 
      MD5 is optionally employed for authentication. Sequence numbers
      are employed as security against replay attacks.

   Deployment: 
      Network elements: TPACT is prototyped and being evaluated on
      multiple vendor L4 switches.  Caching proxies: TPACT is
      prototyped and being evaluated on multiple vendor caches.

   Submitter: 
      John Martin, Network Appliance, [email-masked]

8.3 SOCKS

   Authoritative reference: 
      RFC1928 SOCKS Protocol Version 5 [17]

   Description: 
      SOCKS is primarily used as a proxy cache to firewall protocol. 
      Although, firewalls don't conform to the narrowly defined network
      element definition of routers and switches, they are a integral
      part of the network infrastructure.  When used in conjunction
      with a firewall, SOCKS provides a authenticated tunnel between
      the proxy cache and the firewall.

   Security: 
      A extensive framework provides for multiple authentication
      methods.  Currently, SSL, CHAP, DES, 3DES are known to be
      available.

   Deployment: 
      SOCKS is been widely deployed in the Internet.

   Submitter: 
      Document editors.

Melve, et. al.           Expires April 7, 2000                 [Page 28]

Internet-Draft               WREC Taxonomy                  October 1999

9. Security Considerations

   This document is provides a taxonomy for web caching and
   replication. Recommended practice, architecture and protocols are
   not described in detail.

   Replication and caching means copying objects. There are legal
   implication of making and keeping transient or permanent copies,
   these are not covered in the security considerations.

   Information on security in each protocol is provided in the
   description of the protocol, and in the accompanying documentation
   of each protocol. HTTP security is discussed in section 15 of
   RFC2616[6], the HTTP/1.1 specification, and to a lesser extent in
   RFC1945[15], the HTTP/1.0 specification. RFC2616 contains security
   consideration for HTTP proxies.

   Caching proxies have the same security issues as other application
   level proxies. Application level proxies are not covered in these
   security considerations. Authentication based on client IP number is
   problematic when connecting through a proxy, details are not
   discussed here.

9.1 Authentication

   Requests for web objects and responses to such requests may go to
   replicas and/or flow through proxies. The integrity of the
   communication needs to be preserved, to ensure protection of access
   to the communication and protect the communication exchange from
   unintended change. In the case of security breach, the culprit needs
   to be identified

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

9.1.2 Trusted third party

   A proxy must either be trusted to act on behalf of 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.

Melve, et. al.           Expires April 7, 2000                 [Page 29]

Internet-Draft               WREC Taxonomy                  October 1999

9.1.3 Authentication based on IP number

   Authentication based on client IP number is problematic when
   connecting through a proxy, as the authenticating server sees the
   proxy's IP number. One (not recommended) solution to this is
   spoofing the client's IP number.

   Authentication based on IP number assumes that the end-to-end
   properties of the Internet are preserved. This is typically not the
   case for a network transparent proxy.

9.2 Privacy

9.2.1 Trusted third party

   When using a replication service, you need to trust both the replica
   and the object location service. A object location service is used
   to find the replicated object. Current examples include DNS round
   robin, manual mirror lists, URNs, HTTP redirecting.

   Redirection of traffic, either by redirecting to replicas or by
   redirection done by proxies, may introduce third parties the end
   user and/or origin server need to trust. In the case of network
   transparent proxies, such trusted third parties are often unknown to
   both end points of the communication. Unknown trusted third parties
   may have security implications.

   Both proxies and location services may have access to aggregated
   access information. A proxy typically knows about all access by all
   the clients using it, information that is more sensitive than the
   information held by one origin server.

9.2.2 Logs and legal implications

   Logs from proxies need to be kept secure, as they provide
   information about users and end user patterns.  A proxy log is even
   more sensitive than a web server log, as all requests from the user
   population goes through the proxy. Logs from replication servers may
   need to be amalgamated to get aggregated statistics from a service,
   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 does not necessarily make objects cacheable, as is the
   case of SSL encrypted web sessions.

Melve, et. al.           Expires April 7, 2000                 [Page 30]

Internet-Draft               WREC Taxonomy                  October 1999

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 location
   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 a network transparent proxy
   is denial of service since the end to end nature of the Internet is
   destroyed without the end users knowledge.

9.3.2 Replay attack

   A caching proxy is by definition a replay attack.

9.3.3 Stupid configuration of proxies

   It is quite easy to have a stupid configuration which will harm
   service for end users. 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. Legal implications of replication and caching is
   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 only
   available at network level equipment in a proxy-free world. Some
   network level equipment may have required physical access to get
   sensitive information, and introducing application level components
   may require additional system security.

Melve, et. al.           Expires April 7, 2000                 [Page 31]

Internet-Draft               WREC Taxonomy                  October 1999

10. Acknowledgements

   [Ed note: No decision made on authors list. Submitters of individual
   entries are acknowledged in the text. Need to sort out how to give
   credits where they are due.]

   David Forster, Cisco, [email-masked] provided info on
   Out-of-path Transparent Caching Proxies.

   Alex Rousskov, David Forster, Josh Cohen and John Martin for
   protocol information.

   John Dilley, Ivan Lovric and Joe Touch for terminology and taxonomy
   information.

   David Forster, Josh Cohen, Henrik Nordstrom and Patrick McManus for
   their help in defining proxy transparency.

Melve, et. al.           Expires April 7, 2000                 [Page 32]

Internet-Draft               WREC Taxonomy                  October 1999

References

   [1]  Wessels, D., "Squid FAQ: Transparent Caching/Proxying.", July
        1999.

   [2]  Danzig, P. and K.L. Swartz, "Transparent, Scalable, Failsafe
        Web Caching", July 1999.

   [3]  Williams, B., "Transparent Web Caching Solutions.", July 1999.

   [4]  Hain, T., "Architectural Implications of NAT (Work in
        Progress).", July 1999.

   [5]  Melve, I., Slettjord, L., Verschuren, T. and H. Bekker, "Web
        caching architecture; Technical report European Union
        RE1004-M4.3", January 1999.

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

   [7]  Netscape, Inc., "Navigator Proxy Auto-Config File Format.",
        July 1999.

   [8]  Gauthier, P., Cohen, J., Dunsmuir, M. and C. Perkins, "The Web
        Proxy Auto-Discovery Protocol (work in progress)", June 1999.

   [9]  Valloppppillil, V. and K.W. Ross, "Cache Array Routing Protocol
        (work in progress)", January 1999.

   [10]  Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP),
         Version 2", RFC 2186, September 1997.

   [11]  Wessels, D. and K. Claffy, "Application of Internet Cache
         Protocol (ICP), Version 2", RFC 2187, September 1997.

   [12]  Lovric, I., "Internet Cache Protocol Extension (work in
         progress)", January 1999.

   [13]  Wessels, D., "ICP Home Page", January 1999.

   [14]  University of Southern California and  , "Internet Cache
         Protocol Specification 1.4", September 1994.

   [15]  Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
         Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.

   [16]  Cisco Systems, "Cisco Web Cache Coordination Protocol V1.0
         (work in progress)", January 1999.

Melve, et. al.           Expires April 7, 2000                 [Page 33]

Internet-Draft               WREC Taxonomy                  October 1999

   [17]  "SOCKS Protocol Version 5", RFC 1928, January 1999.

   [18]  Moore, K., "On the use of HTTP as a Substrate for Other
         Protocols (work in progress)", January 1999.

   [19]  Brisco, T., "DNS Support for Load Balancing", RFC 1794,
         January 1999.

   [20]  "Transparent Proxy Agent Control Protocol (work in progress)",
         January 1999.

   [21]  "Pre-filling a cache - A satellite overview (work in
         progress).", January 1999.

   [22]  Hamilton, M., Rousskov, A. and D. Wessels, "Cache Digest
         specification - version 5", December 1998.

   [23]  Vixie, P. and D. Wessels, "Hyper Text Caching Protocol
         (HTCP/0.0)  (work in progress)", August 1999.

   [24]  http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html

Authors' Addresses

   Ingrid Melve
   UNINETT
   Tempeveien 22
   Trondheim
   Norway

   Phone: +47 73 55 79 07
   EMail: [email-masked]

   Gary Tomlinson
   Novell Inc.
   122 East 1700 South
   Provo, Utah  84606
   USA

   Phone: +1 801 861 7021
   EMail: [email-masked]

Melve, et. al.           Expires April 7, 2000                 [Page 34]

Internet-Draft               WREC Taxonomy                  October 1999

   Ian Cooper
   Mirror Image Internet, Inc.
   18 Commerce Way
   Suite 4800
   Woburn, MA  01801
   USA

   Phone: +1 781 939 0735
   EMail: [email-masked]

Melve, et. al.           Expires April 7, 2000                 [Page 35]

Internet-Draft               WREC Taxonomy                  October 1999

Full Copyright Statement

   Copyright (C) The Internet Society (1999). 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.

Melve, et. al.           Expires April 7, 2000                 [Page 36]

---

From: [email-masked]
Date: Mon, 11 Oct 1999 14:50:11 -0700 (PDT)

Ian,
	How does the following look as text for 3.2.2?
					Ted

3.2.2 Client or Proxy to Surrogate 
 
   A client or proxy may communicate with zero or more surrogates for
   requests intended for one or more origin servers.  Where a
   surrogate is not available, the client may communicate directly
   with an origin server.

                              -----------------        
                              |    Client     |
                              |               |
                              -----------------
				      |
				      |
                              -----------------         
                              |   Surrogate   |
                              |               |
                              -----------------
			      /      |        \
			     /       |         \ 
                            /        |          \
                           /   	     |           \
                          /          |            \
	                 /           |             \
       ------------------     -----------------     ------------------
       |     Origin     |     |    Origin     |     |     Origin     |
       |     Server     |     |    Server     |     |     Server     |
       ------------------     -----------------     ------------------

> 
> 
> ----=_szX+N5Vkph66KxjcrC2aZpPs4RI1.MFSBCHJLHS
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> ----=_szX+N5Vkph66KxjcrC2aZpPs4RI1.MFSBCHJLHS
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> Content-Description: draft-ietf-wrec-taxonomy-02e.txt
> Content-Disposition: inline
> 
> 
> 
> ----=_szX+N5Vkph66KxjcrC2aZpPs4RI1.MFSBCHJLHS--
>