Transparent content negotiation defines four dimensions of
   negotiation:

      1. Media type (MIME type)
      2. Charset
      3. Language
      4. Features

   The first three dimensions have traditionally been present in HTTP.
   The fourth dimension is added by this specification.  Additional
   dimensions, beyond the four mentioned above, could be added by future
   specifications.

   Negotiation on the content encoding of a response (gzipped,
   compressed, etc.) is left outside of the realm of transparent
   negotiation.   See section 10.8 for more information.

4.8 Feature negotiation

   Feature negotiation intends to provide for all areas of negotiation
   not covered by the type, charset, and language dimensions.  Examples
   are negotiation on

      * HTML extensions
      * Extensions of other media types
      * Color capabilities of the user agent
      * Screen size
      * Output medium (screen, paper, ...)
      * Preference for speed vs. preference for graphical detail

   The feature negotiation framework (section 6) is the principal means
   by which transparent negotiation offers extensibility; a new
   dimension of negotiation (really a sub-dimension of the feature
   dimension) can be added without the need for a new standards effort
   by the simple registration of a `feature tag'.






 
RFC 2295            Transparent Content Negotiation           March 1998


4.9 Length of variant lists

   As a general rule, variant lists should be short: it is expected that
   a typical transparently negotiable resource will have 2 to 10
   variants, depending on its purpose.  Variant lists should be short
   for a number of reasons:

     1. The user must be able to pick a variant by hand to correct a
        bad automatic choice, and this is more difficult with a long
        variant list.

     2. A large number of variants will decrease the efficiency of
        internet proxy caches.

     3. Long variant lists will make some transparently negotiated
        responses longer.

   In general, it is not desirable to create a transparently negotiable
   resource with hundreds of variants in order to fine-tune the
   graphical presentation of a resource.  Any graphical fine-tuning
   should be done, as much as possible, by using constructs which act at
   the user agent side, for example

      <img src=titlebanner.gif width=100%
      alt="MegaBozo Corp">

   In order to promote user agent side fine tuning, which is more
   scalable than fine tuning over the network, user agents which
   implement a scripting language for content rendering are encouraged
   to make the availability of this language visible for transparent
   content negotiation, and to allow rendering scripts to access the
   capabilities and preferences data used for content negotiation, as
   far as privacy considerations permit this.

4.10 Relation with other negotiation schemes

   The HTTP/1.x protocol suite allows for many different negotiation
   mechanisms.  Transparent content negotiation specializes in scalable,
   interoperable negotiation of content representations at the HTTP
   level.  It is intended that transparent negotiation can co-exist with
   other negotiation schemes, both open and proprietary, which cover
   different application domains or work at different points in the
   author-to-user chain.  Ultimately, it will be up to the resource
   author to decide which negotiation mechanism, or combination of
   negotiation mechanisms, is most appropriate for the task at hand.







 
RFC 2295            Transparent Content Negotiation           March 1998