5  Variant descriptions

5.1 Syntax

   A variant can be described in a machine-readable way with a variant
   description.

       variant-description =
                  "{" <"> URI <"> source-quality *variant-attribute"}"

       source-quality = qvalue

       variant-attribute = "{" "type" media-type "}"
                         | "{" "charset" charset "}"
                         | "{" "language"  1#language-tag "}"
                         | "{" "length" 1*DIGIT "}"
                         | "{" "features" feature-list "}"
                         | "{" "description"
                                     quoted-string [ language-tag ] "}"
                         | extension-attribute

       extension-attribute = "{" extension-name extension-value "}"
       extension-name      = token
       extension-value     = *( token | quoted-string | LWS
                              | extension-specials )

       extension-specials  =
                          <any element of tspecials except <"> and "}">

   The feature-list syntax is defined in section 6.4.

   Examples are

      {"paper.2" 0.7 {type text/html} {language fr}}

      {"paper.5" 0.9 {type text/html} {features tables}}

      {"paper.1" 0.001}

   The various attributes which can be present in a variant description
   are covered in the subsections below.  Each attribute may appear only
   once in a variant description.

5.2 URI

   The URI attribute gives the URI of the resource from which the
   variant can be retrieved with a GET request.  It can be absolute or
   relative to the Request-URI.  The variant resource may vary (on the




 
RFC 2295            Transparent Content Negotiation           March 1998


   Cookie request header, for example), but MUST NOT engage in
   transparent content negotiation itself.

5.3 Source-quality

   The source-quality attribute gives the quality of the variant, as a
   representation of the negotiable resource, when this variant is
   rendered with a perfect rendering engine on the best possible output
   medium.

   If the source-quality is less than 1, it often expresses a quality
   degradation caused by a lossy conversion to a particular data format.
   For example, a picture originally in JPEG form would have a lower
   source quality when translated to the XBM format, and a much lower
   source quality when translated to an ASCII-art variant.  Note
   however, that degradation is a function of the source; an original
   piece of ASCII-art may degrade in quality if it is captured in JPEG
   form.

   The source-quality could also represent a level of quality caused by
   skill of language translation, or ability of the used media type to
   capture the intended artistic expression.

   Servers should use the following table a guide when assigning source
   quality values:

      1.000  perfect representation
      0.900  threshold of noticeable loss of quality
      0.800  noticeable, but acceptable quality reduction
      0.500  barely acceptable quality
      0.300  severely degraded quality
      0.000  completely degraded quality

   The same table can be used by local variant selection algorithms (see
   appendix 19) when assigning degradation factors for different content
   rendering mechanisms.  Note that most meaningful values in this table
   are close to 1.  This is due to the fact that quality factors are
   generally combined by multiplying them, not by adding them.

   When assigning source-quality values, servers should not account for
   the size of the variant and its impact on transmission and rendering
   delays; the size of the variant should be stated in the length
   attribute and any size-dependent calculations should be done by the