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.

   age
     The age of a response is the time since it was sent by, or
     successfully validated with, the origin server.

   fresh
     A response is fresh if its age has not yet exceeded its freshness
     lifetime.

2.2 New terms

   transparently negotiable resource
     A resource, identified by a single URI, which has multiple
     representations (variants) associated with it.  When servicing a
     request on its URI, it allows selection of the best representation
     using the transparent content negotiation mechanism.  A
     transparently negotiable resource always has a variant list bound
     to it, which can be represented as an Alternates header (defined in
     section 8.3).

   variant list
     A list containing variant descriptions, which can be bound to a
     transparently negotiable resource.










 
RFC 2295            Transparent Content Negotiation           March 1998


   variant description
     A machine-readable description of a variant resource, usually found
     in a variant list.  A variant description contains the variant
     resource URI and various attributes which describe properties of
     the variant.  Variant descriptions are defined in section 5.

   variant resource
     A resource from which a variant of a negotiable resource can be
     retrieved with a normal HTTP/1.x GET request, i.e. a GET request
     which does not use transparent content negotiation.

   neighboring variant
     A variant resource is called a neighboring variant resource of some
     transparently negotiable HTTP resource if the variant resource has
     a HTTP URL, and if the absolute URL of the variant resource up to
     its last slash equals the absolute URL of the negotiable resource
     up to its last slash, where equality is determined with the URI
     comparison rules in section 3.2.3 of [1].  The property of being a
     neighboring variant is important because of security considerations
     (section 14.2).  Not all variants of a negotiable resource need to
     be neighboring variants.  However, access to neighboring variants
     can be more highly optimized by the use of remote variant selection
     algorithms (section 7) and choice responses (section 10.2).

   remote variant selection algorithm
     A standardized algorithm by which a server can sometimes choose a
     best variant on behalf of a negotiating user agent.  The algorithm
     typically computes whether the Accept- headers in the request
     contain sufficient information to allow a choice, and if so, which
     variant is the best variant.  The use of a remote algorithm can
     speed up the negotiation process.

   list response
     A list response returns the variant list of the negotiable
     resource, but no variant data.  It can be generated when the server
     does not want to, or is not allowed to, return a particular best
     variant for the request.  List responses are defined in section
     10.1.

   choice response
     A choice response returns a representation of the best variant for
     the request, and may also return the variant list of the negotiable
     resource.  It can be generated when the server has sufficient
     information to be able to choose the best variant on behalf the
     user agent, but may only be generated if this best variant is a
     neighboring variant.  Choice responses are defined in section 10.2.






 
RFC 2295            Transparent Content Negotiation           March 1998


   adhoc response
     An adhoc response can be sent by an origin server as an extreme
     measure, to achieve compatibility with a non-negotiating or buggy