response is smaller than or not much larger than a list
        response.  The definition of `not much larger' is left to
        origin server heuristics.  Implies "vlist" and "trans".

      rvsa-version
        The user agent allows origin servers and proxies to run the
        remote variant selection algorithm with the indicated version
        number, or with the same major version number and a higher
        minor version number.  If the algorithm has sufficient
        information to choose a best, neighboring variant, the origin
        server or proxy MAY return a choice response with this
        variant.  Implies "trans".

      "*"
        The user agent allows origin servers and proxies to run any
        remote variant selection algorithm.  The origin server may
        even run algorithms which have not been standardized.  If the
        algorithm has sufficient information to choose a best,
        neighboring variant, the origin server or proxy MAY return a
        choice response with this variant.  Implies "trans".





 
RFC 2295            Transparent Content Negotiation           March 1998


   Servers SHOULD ignore all negotiate-directives they do not
   understand.  If the Negotiate header allows a choice between multiple
   remote variant selection algorithms which are all supported by the
   server, the server SHOULD use some internal precedence heuristics to
   select the best algorithm.

8.5 TCN

   The TCN response header is used by a server to signal that the
   resource is transparently negotiated.

       TCN = "TCN" ":" #( response-type
                        | server-side-override-directive
                        | tcn-extension )

       response-type = "list" | "choice" | "adhoc"

       server-side-override-directive = "re-choose" | "keep"

       tcn-extension = token [ "=" ( token | quoted-string ) ]

   If the resource is not transparently negotiated, a TCN header MUST
   NOT be included in any response.  If the resource is transparently
   negotiated, a TCN header, which includes the response-type value of
   the response, MUST be included in every response with a 2xx status
   code or any 3xx status code, except 304, in which it MAY be included.
   A TCN header MAY also be included, without a response-type value, in
   other responses from transparently negotiated resources.

   A server-side override directive MUST be included if the origin
   server performed a server-side override when choosing the response.
   If the directive is "re-choose", the server MUST include an
   Alternates header with the variant bound to the negotiable resource
   in the response, and user agent SHOULD use its internal variant
   selection algorithm to choose, retrieve, and display the best variant
   from this list.  If the directive is "keep" the user agent SHOULD NOT
   renegotiate on the response, but display it directly, or act on it
   directly if it is a redirection response.

   Clients SHOULD ignore all tcn-extensions they do not understand.

8.6 Variant-Vary

   The Variant-Vary response header can be used in a choice response to
   record any vary information which applies to the variant data (the
   entity body combined with some of the entity headers) contained in
   the response, rather than to the response as a whole.





 
RFC 2295            Transparent Content Negotiation           March 1998


         Variant-Vary  = "Variant-Vary" ":" ( "*" | 1#field-name )

   Use of the Variant-Vary header is discussed in section 10.2.

9  Cache validators

   To allow for correct and efficient caching and revalidation of
   negotiated responses, this specification extends the caching model of
   HTTP/1.1 [1] in various ways.

   This specification does not introduce a `variant-list-max-age'
   directive which explicitly bounds the freshness lifetime of a cached
   variant list, like the `max-age' Cache-Control directive bounds the
   freshness lifetime of a cached response.  However, this specification
   does ensure that a variant list which is sent at a time T by the