variant selection algorithm.  Any constant rendering delay for a
   particular media type (for example due to the startup time of a
   helper application) should be accounted for by the user agent, when
   assigning a quality factor to that media type.





 
RFC 2295            Transparent Content Negotiation           March 1998


5.4 Type, charset, language, and length

   The type attribute of a variant description carries the same
   information as its Content-Type response header counterpart defined
   in [1], except for any charset information, which MUST be carried in
   the charset attribute.  For, example, the header

      Content-Type: text/html; charset=ISO-8859-4

   has the counterpart attributes

      {type text/html} {charset ISO-8859-4}

   The language and length attributes carry the same information as
   their Content-* response header counterparts in [1].  The length
   attribute, if present, MUST thus reflect the length of the variant
   alone, and not the total size of the variant and any objects inlined
   or embedded by the variant.

   Though all of these attributes are optional, it is often desirable to
   include as many attributes as possible, as this will increase the
   quality of the negotiation process.

      Note: A server is not required to maintain a one-to-one
      correspondence between the attributes in the variant description
      and the Content-* headers in the variant response.  For example,
      if the variant description contains a language attribute, the
      response does not necessarily have to contain a Content-Language
      header. If a Content-Language header is present, it does not have
      to contain an exact copy of the information in the language
      attribute.

5.5 Features

   The features attribute specifies how the presence or absence of
   particular feature tags in the user agent affects the overall quality
   of the variant.  This attribute is covered in section 6.4.

5.6 Description

   The description attribute gives a textual description of the variant.
   It can be included if the URI and normal attributes of a variant are
   considered too opaque to allow interpretation by the user.  If a user
   agent is showing a menu of available variants compiled from a variant
   list, and if a variant has a description attribute, the user agent
   SHOULD show the description attribute of the variant instead of
   showing the normal attributes of the variant.  The description field
   uses the UTF-8 character encoding scheme [5], which is a superset of




 
RFC 2295            Transparent Content Negotiation           March 1998


   US-ASCII, with ""%" HEX HEX" encoding.  The optional language tag MAY
   be used to specify the language used in the description text.

5.7 Extension-attribute

   The extension-attribute allows future specifications to incrementally
   define dimensions of negotiation which cannot be created by using the
   feature negotiation framework, and eases content negotiation
   experiments.  In experimental situations, servers MUST ONLY generate
   extension-attributes whose names start with "x-".  User agents SHOULD
   ignore all extension attributes they do not recognize.  Proxies MUST
   NOT run a remote variant selection algorithm if an unknown extension
   attribute is present in the variant list.

6  Feature negotiation

   This section defines the feature negotiation mechanism.  Feature
   negotiation has been introduced in section 4.8.  Appendix 19 contains
   examples of feature negotiation.

6.1 Feature tags

   A feature tag (ftag) identifies something which can be negotiated on,
   for example a property (feature) of a representation, a capability
   (feature) of a user agent, or the preference of a user for a
   particular type of representation.  The use of feature tags need not
   be limited to transparent content negotiation, and not every feature
   tag needs to be usable in the HTTP transparent content negotiation
   framework.

      ftag = token | quoted-string