Subject: Taxonomy terms

From: Ian Cooper <[email-masked]>
Date: Mon, 04 Oct 1999 20:45:54 +0100

The following is the current working copy of the terminology section from the
taxonomy draft for review.  There are still a few terms for which we have no
definitions - please help in fleshing these out.  If you can help on issues
where there's an editor's note I'd also like to hear from you.

[I'm having a few problems with my mail at present, so comments to the list (so
I can read them in the archive) would be preferred.]

--------------------->8--cut here----------------------------------------------
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

   client [6]
      A program that establishes connections for the purpose of sending
      requests.

   server [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 [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
         transparent proxy as described in [6], not what is commonly
         understood within the caching community. Further unspecified
         references in this document relate to the definition found in
         Section 2.6, not to semantically transparent proxies.

         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 [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: There is widespread colloquial mis-use of the term "cache"
         to mean "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 [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 [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 [6]
      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"

2.2 First order derivative terms

   Using the base terms above as a foundation, we construct the
   following terms 

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

   user agent [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 
      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 
      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 

   origin server accelerator 
      an application of a caching proxy where the proxy is placed
      closer to the origin server than to the content consumers in
      order to off-load the handling of cacheable responses from the
      server; also as a means to reduce traffic within the server's
      network.

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

   reverse proxy 
      An intermediary system which acts as both a server and a client
      for the purpose of serving requests on behalf of origin servers.
      Requests are serviced internally or by passing them on to the
      origin server they are representing.  A reverse proxy must
      interpret and, if necessary, rewrite a request message before
      forwarding it. Reverse proxies are often used as server-side
      portals through network firewalls and as helper applications for
      off loading requests from origin servers.

      Ed note; IAN: leaving this as a placeholder until we can work out
         proxies/reverse proxies/surrogates and accelerators

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)

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

<snip>

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.

   [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

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 5 Oct 1999 03:43:18 PDT

I would prefer if it was clearer from the text that the definitions
were copied while the "Note" sections weren't. It might just
be indentation, e.g., indent this document's "note" sections 
*less* than the quoted text rather than more.

Some of your basic terms and notes belong in the revision of RFC 2616 as
it goes to "Standard"; you might consider submitting them as
errata ( http://purl.org/NET/http-errata ).

>       Note: There is widespread colloquial mis-use of the term "cache"

I think you can be less pejorative:
<<The term "cache" used alone often is meant as "caching proxy".>>
but I don't know how widespread this is, actually. Personally, most documents
I've seen are careful about this.

>          load in such a way that the comment is unnecessary?

We should acknowledge there are other motivations for caching other than
reducing response time, including reducing server load and enabling
disconnected operation. But in HTTP

      "A cache stores cacheable responses in order to reduce the response
      time and network bandwidth consumption on future, equivalent
      requests."

could become

      "A cache stores cacheable responses; for example, this may be
      done to reduce the response time and network bandwidth consumption
      on future, equivalent requests."

It's not clear you want to elaborate all of the purposes of a cache
in the definition for a cache.

>    Using the base terms above as a foundation, we construct the

Usually "we" is meant as "the authors of this document", but the
constructed terms were constructed elsewhere. How about
"The following terms are defined in terms of the base terms above:"

>       A proxy with a cache, acting as a server to clients, and a client

This definition is just missing from RFC 2616, since it's used there.
I'd suggest submitting this as an errata.

>       server; the overall master copy of the content, if any

Why is this second-order? The definition is a bit unsatisfactory
since "owner" and "data" aren't defined, nor is "content
production system". I'm not sure what you mean.
 
>       (which may in turn be handled by a proxy).

I'm not sure how this is distinguished from "user agent" or
"client". (Actually, the line between "user agent" and "client"
isn't described very well in RFC 2616.)

>       presentation device for content consumers.

My guess is that both of these should be present in the update to
RFC 2616, and that we should more carefully distinguish between
those constraints that apply to a 'user agent' and those that
apply to a 'browser'. HTTP/1.1 makes some requirements on how
the "user agent" interacts with the "user" in the case of
a "browser" that is inappropriate for other kinds of clients,
e.g., 

   ... user agents SHOULD present to the user the entity returned
   with the response, since that entity is likely to include human-
   readable information which will explain the unusual status.

Larry
-- 
http://www.parc.xerox.com/masinter

---

From: Ian Cooper <[email-masked]>
Date: Thu, 07 Oct 1999 15:37:13 +0100

>*less* than the quoted text rather than more.

Like this?
: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.
<snip>
:   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".

With respect to identifying that the definitions are copied, does the
above clarification work, or would you (also) prefer something in the
intro text?

As for the notes, hope the above is OK - I can't make it any
different.

>errata ( http://purl.org/NET/http-errata ).

OK, will do.

>I've seen are careful about this.

I think I've noticed the same in written documents (although I'm sure
I've seen "proxy cache" a lot), but I note that when speaking (at
least the people I talk to) the phrases "cache" and "proxy" are
substituted for "caching proxy".

>production system". I'm not sure what you mean.

"Server" and the more specific "origin server" are defined.  I added
this term to try and hint at the system that maintained the overall
master copy of the content, for possible inclusion in the replication
side of things.  It didn't seem that origin server correctly conveyed
the required semantics when considering replicas.

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

With many replicas, which could presumably appear to be the origin
server by the above definition, what wording can be used to describe
the system that hold the "master" copy.  (I'm just an editor, if
someone has some better terms please submit them.)

>isn't described very well in RFC 2616.)

On that second point I can see what you mean.  To me a client is just
as defined.  A user agent is an application used by an entity to
request and receive content.  The content consumer is the entity that
makes a request of a user agent.

I've probably not made good enough examples. However, I felt that
"user" implied human too much, and I didn't want the inference that
the entity making requests was a human.