origin server will never be re-used without revalidation by
   semantically transparent caches after the time T+M.  This M is the
   maximum of all freshness lifetimes assigned (using max-age directives
   or Expires headers) by the origin server to

      a. the responses from the negotiable resource itself, and

      b. the responses from its neighboring variant resources

   If no freshness lifetimes are assigned by the origin server, M is the
   maximum of the freshness lifetimes which were heuristically assigned
   by all caches which can re-use the variant list.

9.1 Variant list validators

   A variant list validator is an opaque value which acts as the cache
   validator of a variant list bound to a negotiable resource.

      variant-list-validator = <quoted-string not containing any ";">

   If two responses contain the same variant list validator, a cache can
   treat the Alternates headers in these responses as equivalent (though
   the headers themselves need not be identical).

9.2 Structured entity tags

   A structured entity tag consists of a normal entity tag of which the
   opaque string is extended with a semicolon followed by the text
   (without the surrounding quotes) of a variant list validator:








 
RFC 2295            Transparent Content Negotiation           March 1998


        normal      |  variant list  |   structured
        entity tag  |  validator     |   entity tag
       -------------+----------------+-----------------
         "etag"     |     "vlv"      |   "etag;vlv"
        W/"etag"    |     "vlv"      |  W/"etag;vlv"

   Note that a structured entity tag is itself also an entity tag.  The
   structured nature of the tag allows caching proxies capable of
   transparent content negotiation to perform some optimizations defined
   in section 10.  When not performing such optimizations, a structured
   tag SHOULD be treated as a single opaque value, according to the
   general rules in HTTP/1.1.  Examples of structured entity tags are:

      "xyzzy;1234"  W/"xyzzy;1234"  "gonkxxxx;1234"  "a;b;c;;1234"

   In the last example, the normal entity tag is "a;b;c;" and the
   variant list validator is "1234".

   If a transparently negotiated response includes an entity tag, it
   MUST be a structured entity tag.  The variant list validator in the
   structured tag MUST act as a validator for the variant list contained
   in the Alternates header.  The normal entity tag in the structured
   tag MUST act as a validator of the entity body in the response and of
   all entity headers except Alternates.

9.3 Assigning entity tags to variants

   To allow for correct revalidation of transparently negotiated
   responses by clients, origin servers SHOULD generate all normal
   entity tags for the neighboring variant resources of the negotiable
   resource in such a way that

     1. the same tag is never used by two different variants,
        unless this tag labels exactly the same entity on all occasions,
     2. if one normal tag "X" is a prefix of another normal tag "XY",
        then "Y" must never be a semicolon followed by a variant list
        validator.

10 Content negotiation responses

   If a request on a transparently negotiated resource yields a response
   with a 2xx status code or any 3xx status code except 304, this
   response MUST always be either a list response, a choice response, or
   an adhoc response.  These responses MUST always include a TCN header
   which specifies their type.  Transparently negotiated responses with
   other status codes MAY also include a TCN header.





 
RFC 2295            Transparent Content Negotiation           March 1998


   The conditions under which the different content negotiation
   responses may be sent are defined in section 12.1 for origin servers
   and in section 13 for proxies.