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
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:27 MST