Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2295

Transparent Content Negotiation in HTTP

Pages: 58
Experimental
Part 1 of 2 – Pages 1 to 24
None   None   Next

Top   ToC   RFC2295 - Page 1
Network Working Group                                         K. Holtman
Request for Comments: 2295                                           TUE
Category: Experimental                                           A. Mutz
                                                         Hewlett-Packard
                                                              March 1998


                Transparent Content Negotiation in HTTP

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

ABSTRACT

   HTTP allows web site authors to put multiple versions of the same
   information under a single URL.  Transparent content negotiation is
   an extensible negotiation mechanism, layered on top of HTTP, for
   automatically selecting the best version when the URL is accessed.
   This enables the smooth deployment of new web data formats and markup
   tags.

TABLE OF CONTENTS

   1  Introduction................................................4
    1.1 Background................................................4

   2  Terminology.................................................5
    2.1 Terms from HTTP/1.1.......................................5
    2.2 New terms.................................................6

   3  Notation....................................................8

   4  Overview....................................................9
    4.1 Content negotiation.......................................9
    4.2 HTTP/1.0 style negotiation scheme.........................9
    4.3 Transparent content negotiation scheme...................10
    4.4 Optimizing the negotiation process.......................12
    4.5 Downwards compatibility with non-negotiating user agents.14
    4.6 Retrieving a variant by hand.............................15
    4.7 Dimensions of negotiation................................15
Top   ToC   RFC2295 - Page 2
    4.8 Feature negotiation......................................15
    4.9 Length of variant lists..................................16
    4.10 Relation with other negotiation schemes.................16

   5  Variant descriptions.......................................17
    5.1 Syntax...................................................17
    5.2 URI......................................................17
    5.3 Source-quality...........................................18
    5.4 Type, charset, language, and length......................19
    5.5 Features.................................................19
    5.6 Description..............................................19
    5.7 Extension-attribute......................................20

   6  Feature negotiation........................................20
    6.1 Feature tags.............................................20
    6.1.1 Feature tag values.....................................21
    6.2 Feature sets.............................................21
    6.3 Feature predicates.......................................22
    6.4 Features attribute.......................................24

   7  Remote variant selection algorithms........................25
    7.1 Version numbers..........................................25

   8  Content negotiation status codes and headers...............25
    8.1 506 Variant Also Negotiates..............................25
    8.2 Accept-Features..........................................26
    8.3 Alternates...............................................27
    8.4 Negotiate................................................28
    8.5 TCN......................................................30
    8.6 Variant-Vary.............................................30

   9  Cache validators...........................................31
    9.1 Variant list validators..................................31
    9.2 Structured entity tags...................................31
    9.3 Assigning entity tags to variants........................32

   10 Content negotiation responses..............................32
    10.1 List response...........................................33
    10.2 Choice response.........................................34
    10.3 Adhoc response..........................................37
    10.4 Reusing the Alternates header...........................38
    10.5 Extracting a normal response from a choice response.....39
    10.6 Elaborate Vary headers..................................39
    10.6.1 Construction of an elaborate Vary header..............40
    10.6.2 Caching of an elaborate Vary header...................41
    10.7 Adding an Expires header for HTTP/1.0 compatibility.....41
    10.8 Negotiation on content encoding.........................41
Top   ToC   RFC2295 - Page 3
   11 User agent support for transparent negotiation.............42
    11.1 Handling of responses...................................42
    11.2 Presentation of a transparently negotiated resource.....42

   12 Origin server support for transparent negotiation..........43
    12.1 Requirements............................................43
    12.2 Negotiation on transactions other than GET and HEAD.....45

   13 Proxy support for transparent negotiation..................45

   14 Security and privacy considerations........................46
    14.1 Accept- headers revealing personal information..........46
    14.2 Spoofing of responses from variant resources............47
    14.3 Security holes revealed by negotiation..................47

   15 Internationalization considerations........................47

   16 Acknowledgments............................................47

   17 References.................................................48

   18 Authors' Addresses.........................................48

   19 Appendix: Example of a local variant selection algorithm...49
    19.1 Computing overall quality values........................49
    19.2 Determining the result..................................51
    19.3 Ranking dimensions......................................51

   20 Appendix: feature negotiation examples.....................52
    20.1 Use of feature tags.....................................52
    20.2 Use of numeric feature tags.............................53
    20.3 Feature tag design......................................53

   21 Appendix: origin server implementation considerations......54
    21.1 Implementation with a CGI script........................54
    21.2 Direct support by HTTP servers..........................55
    21.3 Web publishing tools....................................55

   22 Appendix: Example of choice response construction..........55

   23 Full Copyright Statement...................................58
Top   ToC   RFC2295 - Page 4
1  Introduction

   HTTP allows web site authors to put multiple versions of the same
   information under a single URI.  Each of these versions is called a
   `variant'.  Transparent content negotiation is an extensible
   negotiation mechanism for automatically and efficiently retrieving
   the best variant when a GET or HEAD request is made.  This enables
   the smooth deployment of new web data formats and markup tags.

   This specification defines transparent content negotiation as an
   extension on top of the HTTP/1.1 protocol [1].  However, use of this
   extension does not require use of HTTP/1.1: transparent content
   negotiation can also be done if some or all of the parties are
   HTTP/1.0 [2] systems.

   Transparent content negotiation is called `transparent' because it
   makes all variants which exist inside the origin server visible to
   outside parties.

     Note: Some members of the IETF are currently undertaking a number
     of activities which are loosely related to this experimental
     protocol.  First, there is an effort to define a protocol-
     independent registry for feature tags.  The intention is that this
     experimental protocol will be one of the clients of the registry.
     Second, some research is being done on content negotiation systems
     for other transport protocols (like internet mail and internet fax)
     and on generalized negotiation systems for multiple transport
     protocols.  At the time of writing, it is unclear if or when this
     research will lead to results in the form of complete negotiation
     system specifications.  It is also unclear to which extent possible
     future specifications can or will re-use elements of this
     experimental protocol.

1.1 Background

   The addition of content negotiation to the web infrastructure has
   been considered important since the early days of the web.  Among the
   expected benefits of a sufficiently powerful system for content
   negotiation are

     * smooth deployment of new data formats and markup tags will
       allow graceful evolution of the web

     * eliminating the need to choose between a `state of the art
       multimedia homepage' and one which can be viewed by all web users

     * enabling good service to a wider range of browsing
       platforms (from low-end PDA's to high-end VR setups)
Top   ToC   RFC2295 - Page 5
     * eliminating error-prone and cache-unfriendly
       User-Agent based negotiation

     * enabling construction of sites without `click here for the X
       version' links

     * internationalization, and the ability to offer multi-lingual
       content without a bias towards one language.

2  Terminology

   The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
   this document are to be interpreted as described in RFC 2119 [4].

   This specification uses the term `header' as an abbreviation for for
   `header field in a request or response message'.

2.1 Terms from HTTP/1.1

   This specification mostly uses the terminology of the HTTP/1.1
   specification [1].  For the convenience of the reader, this section
   reproduces some key terminology definition from [1].

   request
     An HTTP request message.

   response
     An HTTP response message.

   resource
     A network data object or service that can be identified by a URI.
     Resources may be available in multiple representations (e.g.
     multiple languages, data formats, size, resolutions) or vary in
     other ways.

   content negotiation
     The mechanism for selecting the appropriate representation when
     servicing a request.

   client
     A program that establishes connections for the purpose of sending
     requests.

   user agent
     The client which initiates a request.  These are often browsers,
     editors, spiders (web-traversing robots), or other end user tools.
Top   ToC   RFC2295 - Page 6
   server
     An application program that accepts connections in order to service
     requests by sending back responses.  Any given program may be
     capable of being both a client and a server; our use of these terms
     refers only to the role being performed by the program for a
     particular connection, rather than to the program's capabilities in
     general.  Likewise, any server may act as an origin server, proxy,
     gateway, or tunnel, switching behavior based on the nature of each
     request.

   origin server
     The server on which a given resource resides or is to be created.

   proxy
     An intermediary program which acts as both a server and a client
     for the purpose of making requests on behalf of other clients.
     Requests are serviced internally or by passing them on, with
     possible translation, to other servers.  A proxy must implement
     both the client and server requirements of this specification.

   age
     The age of a response is the time since it was sent by, or
     successfully validated with, the origin server.

   fresh
     A response is fresh if its age has not yet exceeded its freshness
     lifetime.

2.2 New terms

   transparently negotiable resource
     A resource, identified by a single URI, which has multiple
     representations (variants) associated with it.  When servicing a
     request on its URI, it allows selection of the best representation
     using the transparent content negotiation mechanism.  A
     transparently negotiable resource always has a variant list bound
     to it, which can be represented as an Alternates header (defined in
     section 8.3).

   variant list
     A list containing variant descriptions, which can be bound to a
     transparently negotiable resource.
Top   ToC   RFC2295 - Page 7
   variant description
     A machine-readable description of a variant resource, usually found
     in a variant list.  A variant description contains the variant
     resource URI and various attributes which describe properties of
     the variant.  Variant descriptions are defined in section 5.

   variant resource
     A resource from which a variant of a negotiable resource can be
     retrieved with a normal HTTP/1.x GET request, i.e. a GET request
     which does not use transparent content negotiation.

   neighboring variant
     A variant resource is called a neighboring variant resource of some
     transparently negotiable HTTP resource if the variant resource has
     a HTTP URL, and if the absolute URL of the variant resource up to
     its last slash equals the absolute URL of the negotiable resource
     up to its last slash, where equality is determined with the URI
     comparison rules in section 3.2.3 of [1].  The property of being a
     neighboring variant is important because of security considerations
     (section 14.2).  Not all variants of a negotiable resource need to
     be neighboring variants.  However, access to neighboring variants
     can be more highly optimized by the use of remote variant selection
     algorithms (section 7) and choice responses (section 10.2).

   remote variant selection algorithm
     A standardized algorithm by which a server can sometimes choose a
     best variant on behalf of a negotiating user agent.  The algorithm
     typically computes whether the Accept- headers in the request
     contain sufficient information to allow a choice, and if so, which
     variant is the best variant.  The use of a remote algorithm can
     speed up the negotiation process.

   list response
     A list response returns the variant list of the negotiable
     resource, but no variant data.  It can be generated when the server
     does not want to, or is not allowed to, return a particular best
     variant for the request.  List responses are defined in section
     10.1.

   choice response
     A choice response returns a representation of the best variant for
     the request, and may also return the variant list of the negotiable
     resource.  It can be generated when the server has sufficient
     information to be able to choose the best variant on behalf the
     user agent, but may only be generated if this best variant is a
     neighboring variant.  Choice responses are defined in section 10.2.
Top   ToC   RFC2295 - Page 8
   adhoc response
     An adhoc response can be sent by an origin server as an extreme
     measure, to achieve compatibility with a non-negotiating or buggy
     client if this compatibility cannot be achieved by sending a list
     or choice response.  There are very little requirements on the
     contents of an adhoc response.  Adhoc responses are defined in
     section 10.3.

   Accept- headers
     The request headers: Accept, Accept-Charset, Accept-Language, and
     Accept-Features.

   supports transparent content negotiation
     From the viewpoint of an origin server or proxy, a user agent
     supports transparent content negotiation if and only if it sends a
     Negotiate header (section 8.4) which indicates such support.

   server-side override
     If a request on a transparently negotiated resource is made by a
     client which supports transparent content negotiation, an origin
     server is said to perform a server-side override if the server
     ignores the directives in the Negotiate request header, and instead
     uses a custom algorithm to choose an appropriate response.  A
     server-side override can sometimes be used to work around known
     client bugs.  It could also be used by protocol extensions on top
     of transparent content negotiation.

3  Notation

   The version of BNF used in this document is taken from [1], and many
   of the nonterminals used are defined in [1].  Note that the
   underlying charset is US-ASCII.

   One new BNF construct is added:

      1%rule

   stands for one or more instances of "rule", separated by whitespace:

      1%rule =  rule *( 1*LWS rule )

   This specification also introduces

      number = 1*DIGIT

      short-float = 1*3DIGIT [ "." 0*3DIGIT ]
Top   ToC   RFC2295 - Page 9
   This specification uses the same conventions as in [1] (see section
   1.2 of [1]) for defining the significance of each particular
   requirement.

4  Overview

   This section gives an overview of transparent content negotiation.
   It starts with a more general discussion of negotiation as provided
   by HTTP.

4.1 Content negotiation

   HTTP/1.1 allows web site authors to put multiple versions of the same
   information under a single resource URI.  Each of these versions is
   called a `variant'. For example, a resource http://x.org/paper could
   bind to three different variants of a paper:

         1. HTML, English
         2. HTML, French
         3. Postscript, English

   Content negotiation is the process by which the best variant is
   selected if the resource is accessed.  The selection is done by
   matching the properties of the available variants to the capabilities
   of the user agent and the preferences of the user.

   It has always been possible under HTTP to have multiple
   representations available for one resource, and to return the most
   appropriate representation for each subsequent request.  However,
   HTTP/1.1 is the first version of HTTP which has provisions for doing
   this in a cache-friendly way.  These provisions include the Vary
   response header, entity tags, and the If-None-Match request header.

4.2 HTTP/1.0 style negotiation scheme

   The HTTP/1.0 protocol elements allow for a negotiation scheme as
   follows:

      Server _____ proxy _____ proxy _____ user
      x.org        cache       cache       agent

        < ----------------------------------
        |      GET http://x.org/paper
        |          Accept- headers
      choose
        |
         ---------------------------------- >
                    Best variant
Top   ToC   RFC2295 - Page 10
   When the resource is accessed, the user agent sends (along with its
   request) various Accept- headers which express the user agent
   capabilities and the user preferences.  Then the origin server uses
   these Accept- headers to choose the best variant, which is returned
   in the response.

   The biggest problem with this scheme is that it does not scale well.
   For all but the most minimal user agents, Accept- headers expressing
   all capabilities and preferences would be very large, and sending
   them in every request would be hugely inefficient, in particular
   because only a small fraction of the resources on the web have
   multiple variants.

4.3 Transparent content negotiation scheme

   The transparent content negotiation scheme eliminates the need to
   send huge Accept- headers, and nevertheless allows for a selection
   process that always yields either the best variant, or an error
   message indicating that user agent is not capable of displaying any
   of the available variants.

   Under the transparent content negotiation scheme, the server sends a
   list with the available variants and their properties to the user
   agent.  An example of a list with three variants is

      {"paper.1" 0.9 {type text/html} {language en}},
      {"paper.2" 0.7 {type text/html} {language fr}},
      {"paper.3" 1.0 {type application/postscript} {language en}}

   The syntax and semantics of the variant descriptions in this list are
   covered in section 5.  When the list is received, the user agent can
   choose the best variant and retrieve it.  Graphically, the
   communication can be represented as follows:
Top   ToC   RFC2295 - Page 11
      Server _____ proxy _____ proxy _____ user
      x.org        cache       cache       agent

        < ----------------------------------
        |      GET http://x.org/paper
        |
        ----------------------------------- >         [list response]
                  return of list            |
                                         choose
                                            |
        < ----------------------------------
        |  GET http://x.org/paper.1
        |
         ---------------------------------- >         [normal response]
                return of paper.1

   The first response returning the list of variants is called a `list
   response'.  The second response is a normal HTTP response: it does
   not contain special content negotiation related information.  Only
   the user agent needs to know that the second request actually
   retrieves a variant.  For the other parties in the communication, the
   second transaction is indistinguishable from a normal HTTP
   transaction.

   With this scheme, information about capabilities and preferences is
   only used by the user agent itself.  Therefore, sending such
   information in large Accept- headers is unnecessary.  Accept- headers
   do have a limited use in transparent content negotiation however; the
   sending of small Accept- headers can often speed up the negotiation
   process. This is covered in section 4.4.

   List responses are covered in section 10.1.  As an example, the list
   response in the above picture could be:

     HTTP/1.1 300 Multiple Choices
     Date: Tue, 11 Jun 1996 20:02:21 GMT
     TCN: list
     Alternates: {"paper.1" 0.9 {type text/html} {language en}},
                 {"paper.2" 0.7 {type text/html} {language fr}},
                 {"paper.3" 1.0 {type application/postscript}
                     {language en}}
     Vary: negotiate, accept, accept-language
     ETag: "blah;1234"
     Cache-control: max-age=86400
     Content-Type: text/html
     Content-Length: 227
     <h2>Multiple Choices:</h2>
     <ul>
Top   ToC   RFC2295 - Page 12
     <li><a href=paper.1>HTML, English version</a>
     <li><a href=paper.2>HTML, French version</a>
     <li><a href=paper.3>Postscript, English version</a>
     </ul>

   The Alternates header in the response contains the variant list.  The
   Vary header is included to ensure correct caching by plain HTTP/1.1
   caches (see section 10.6).  The ETag header allows the response to be
   revalidated by caches, the Cache-Control header controls this
   revalidation.  The HTML entity included in the response allows the
   user to select the best variant by hand if desired.

4.4 Optimizing the negotiation process

   The basic transparent negotiation scheme involves two HTTP
   transactions: one to retrieve the list, and a second one to retrieve
   the chosen variant.  There are however several ways to `cut corners'
   in the data flow path of the basic scheme.

   First, caching proxies can cache both variant lists and variants.
   Such caching can reduce the communication overhead, as shown in the
   following example:

      Server _____ proxy _____ proxy __________ user
      x.org        cache       cache            agent

                                 < --------------
                                 |  GET ../paper
                                 |
                               has the list
                               in cache
                                 |
                                  -------------  >  [list response]
                                           list  |
                                                 |
                                              choose
                                                 |
                     < --------------------------
                     |   GET ../paper.1
                     |
                  has the variant
                  in cache
                     |
                      -------------------------- >  [normal response]
                         return of paper.1
Top   ToC   RFC2295 - Page 13
   Second, the user agent can send small Accept- headers, which may
   contain enough information to allow the server to choose the best
   variant and return it directly.

      Server _____ proxy _____ proxy _____ user
      x.org        cache       cache       agent

        < ----------------------------------
        |      GET http://x.org/paper
        |       small Accept- headers
        |
      able to choose on
      behalf of user agent
        |
         ---------------------------------- >    [choice response]
              return of paper.1 and list

   This choosing based on small Accept- headers is done with a `remote
   variant selection algorithm'.  Such an algorithm takes the variant
   list and the Accept- headers as input.  It then computes whether the
   Accept- headers contain sufficient information to choose on behalf of
   the user agent, and if so, which variant is the best variant.  If the
   best variant is a neighboring variant, it may be returned, together
   with the variant list, in a choice response.

   A server may only choose on behalf of a user agent supporting
   transparent content negotiation if the user agent explicitly allows
   the use of a particular remote variant selection algorithm in the
   Negotiate request header.  User agents with sophisticated internal
   variant selection algorithms may want to disallow a remote choice, or
   may want to allow it only when retrieving inline images.  If the
   local algorithm of the user agent is superior in only some difficult
   areas of negotiation, it is possible to enable the remote algorithm
   for the easy areas only.  More information about the use of a remote
   variant selection algorithm can be found in [3].

   Choice responses are covered in section 10.2.  For example, the
   choice response in the above picture could be:

     HTTP/1.1 200 OK
     Date: Tue, 11 Jun 1996 20:05:31 GMT
     TCN: choice
     Content-Type: text/html
     Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
     Content-Length: 5327
     Cache-control: max-age=604800
     Content-Location: paper.1
     Alternates: {"paper.1" 0.9 {type text/html} {language en}},
Top   ToC   RFC2295 - Page 14
                 {"paper.2" 0.7 {type text/html} {language fr}},
                 {"paper.3" 1.0 {type application/postscript}
                     {language en}}
     Etag: "gonkyyyy;1234"
     Vary: negotiate, accept, accept-language
     Expires: Thu, 01 Jan 1980 00:00:00 GMT

     <title>A paper about ....

   Finally, the above two kinds of optimization can be combined; a
   caching proxy which has the list will sometimes be able to choose on
   behalf of the user agent.  This could lead to the following
   communication pattern:

      Server _____ proxy _____ proxy __________ user
      x.org        cache       cache            agent

                                 < ---------------
                                 |  GET ../paper
                                 |  small Accept
                                 |
                              able to choose
                                on behalf
                                 |
                     < ----------
                     |  GET ../paper.1
                     |
                      ---------- >   [normal response]
                        paper.1  |
                                  ---------------- >  [choice response]
                                   paper.1 and list

   Note that this cutting of corners not only saves bandwidth, it also
   eliminates delays due to packet round trip times, and reduces the
   load on the origin server.

4.5 Downwards compatibility with non-negotiating user agents

   To handle requests from user agents which do not support transparent
   content negotiation, this specification allows the origin server to
   revert to a HTTP/1.0 style negotiation scheme.  The specification of
   heuristics for such schemes is beyond the scope of this document.
Top   ToC   RFC2295 - Page 15
4.6 Retrieving a variant by hand

   It is always possible for a user agent to retrieve the variant list
   which is bound to a negotiable resource.  The user agent can use this
   list to make available a menu of all variants and their
   characteristics to the user.  Such a menu allows the user to randomly
   browse other variants, and makes it possible to manually correct any
   sub-optimal choice made by the automatic negotiation process.

4.7 Dimensions of negotiation

   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'.
Top   ToC   RFC2295 - Page 16
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

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

   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.
Top   ToC   RFC2295 - Page 17
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
Top   ToC   RFC2295 - Page 18
   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
   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.
Top   ToC   RFC2295 - Page 19
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
Top   ToC   RFC2295 - Page 20
   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

      Note: A protocol-independent system for feature tag registration
      is currently being developed in the IETF.  This specification does
      not define any feature tags.  In experimental situations, the use
      of tags which start with "x." is encouraged.

   Feature tags are used in feature sets (section 6.2) and in feature
   predicates (section 6.3).  Feature predicates are in turn used in
   features attributes (section 6.4), which are used in variant
   descriptions (section 5).  Variant descriptions can be transmitted in
   Alternates headers (section 8.3).

   The US-ASCII charset is used for feature tags.  Feature tag
   comparison is case-insensitive.  A token tag XYZ is equal to a
   quoted-string tag "XYZ". Examples are

      tables, fonts, blebber, wolx, screenwidth, colordepth
Top   ToC   RFC2295 - Page 21
   An example of the use of feature tags in a variant description is:

      {"index.html" 1.0 {type text/html} {features tables frames}}

   This specification follows general computing practice in that it
   places no restrictions on what may be called a feature.  At the
   protocol level, this specification does not distinguish between
   different uses of feature tags: a tag will be processed in the same
   way, no matter whether it identifies a property, capability, or
   preference.  For some tags, it may be fluid whether the tag
   represents a property, preference, or capability.  For example, in
   content negotiation on web pages, a "textonly" tag would identify a
   capability of a text-only user agent, but the user of a graphical
   user agent may use this tag to specify that text-only content is
   preferred over graphical content.

6.1.1 Feature tag values

   The definition of a feature tag may state that a feature tag can have
   zero, one, or more values associated with it.  These values
   specialize the meaning of the tag.  For example, a feature tag
   `paper' could be associated with the values `A4' and `A5'.

      tag-value  = token | quoted-string

   The US-ASCII charset is used for feature tag values.  Equality
   comparison for tag values MUST be done with a case-sensitive, octet-
   by-octet comparison, where any ""%" HEX HEX" encodings MUST be
   processed as in [1].  A token value XYZ is equal to a quoted-string
   value "XYZ".

6.2 Feature sets

   The feature set of a user agent is a data structure which records the
   capabilities of the user agent and the preferences of the user.

   Feature sets are used by local variant selection algorithms (see
   appendix 19 for an example).  A user agent can use the Accept-
   Features header (section 8.2) to make some of the contents of its
   feature set known to remote variant selection algorithms.

   Structurally, a feature set is a possibly empty set, containing
   records of the form

      ( feature tag , set of feature tag values )
Top   ToC   RFC2295 - Page 22
   If a record with a feature tag is present in the set, this means that
   the user agent implements the corresponding capability, or that the
   user has expressed the corresponding preference.

   Each record in a feature set has a, possibly empty, set of tag
   values.  For feature tags which cannot have values associated with
   it, this set is always empty.  For feature tags which can have zero,
   one, or more values associated with it, this set contains those
   values currently associated with the tag.  If the set of a feature
   tag T has the value V in it, it is said that `the tag T is present
   with the value V'.

   This specification does not define a standard notation for feature
   sets.  An example of a very small feature set, in a mathematical
   notation, is

      { ( "frames" , { } ) ,
        ( "paper"  , { "A4" , "A5" } )
      }

   As feature registration is expected to be an ongoing process, it is
   generally not possible for a user agent to know the meaning of all
   feature tags it can possibly encounter in a variant description.  A
   user agent SHOULD treat all features tags unknown to it as absent
   from its feature set.

   A user agent may change the contents of its feature set depending on
   the type of request, and may also update it to reflect changing
   conditions, for example a change in the window size.  Therefore, when
   considering feature negotiation, one usually talks about `the feature
   set of the current request'.

6.3 Feature predicates

   Feature predicates are predicates on the contents of feature sets.
   They appear in the features attribute of a variant description.

      fpred = [ "!" ] ftag
            | ftag ( "=" | "!=" ) tag-value
            | ftag "=" "[" numeric-range "]"

      numeric-range = [ number ] "-" [ number ]

   Feature predicates are used in features attributes (section 6.4),
   which are used in variant descriptions (section 5).  Variant
   descriptions can be transmitted in Alternates headers (section 8.3).
Top   ToC   RFC2295 - Page 23
   Examples of feature predicates are

      blebber, !blebber, paper=a4, colordepth=5, blex!=54,
      dpi=[300-599], colordepth=[24-]

   Using the feature set of the current request, a user agent SHOULD
   compute the truth value of the different feature predicates as
   follows.

      ftag       true if the feature is present, false otherwise

      !ftag      true if the feature is absent, false otherwise

      ftag=V     true if the feature is present with the value V,
                 false otherwise,

      ftag!=V    true if the feature is not present with the value V,
                 false otherwise,

      ftag=[N-M] true if the feature is present with at least one
                 numeric value, while the highest value with which it
                 is present in the range N-M, false otherwise.  If N
                 is missing, the lower bound is 0.  If M is missing,
                 the upper bound is infinity.

   As an example, with the feature set

       { ( "blex"       , { } ),
         ( "colordepth" , { "5" } ),
         ( "UA-media"   , { "stationary" } ),
         ( "paper"      , { "A4", "A3" } ) ,
         ( "x-version"  , { "104", "200" } )
       }

   the following predicates are true:

   blex, colordepth=[4-], colordepth!=6, colordepth, !screenwidth, UA-
   media=stationary, UA-media!=screen, paper=A4, paper =!A0,
   colordepth=[ 4 - 6 ], x-version=[100-300], x-version=[200-300]

   and the following predicates are false:

      !blex, blebber, colordepth=6, colordepth=foo, !colordepth,
      screenwidth, screenwidth=640, screenwidth!=640, x-version=99, UA-
      media=screen, paper=A0, paper=a4, x-version=[100-199], wuxta
Top   ToC   RFC2295 - Page 24
6.4 Features attribute

      The features attribute, for which section 5.1 defines the syntax

      "{" "features" feature-list "}"

   is used in a variant description to specify how the presence or
   absence of particular feature tags in the user agent affects the
   overall quality of the variant.

       feature-list = 1%feature-list-element

       feature-list-element = ( fpred | fpred-bag )
                              [ ";" [ "+" true-improvement  ]
                                    [ "-" false-degradation ]
                              ]

       fpred-bag = "[" 1%fpred "]"

       true-improvement   =  short-float
       false-degradation  =  short-float

   Features attributes are used in variant descriptions (section 5).
   Variant descriptions can be transmitted in Alternates headers
   (section 8.3).

   Examples are:

       {features !textonly [blebber !wolx] colordepth=3;+0.7}

       {features !blink;-0.5 background;+1.5 [blebber !wolx];+1.4-0.8}

   The default value for the true-improvement is 1.  The default value
   for the false-degradation is 0, or 1 if a true-improvement value is
   given.

   A user agent SHOULD, and a remote variant selection algorithm MUST
   compute the quality degradation factor associated with the features
   attribute by multiplying all quality degradation factors of the
   elements of the feature-list.  Note that the result can be a factor
   greater than 1.

   A feature list element yields its true-improvement factor if the
   corresponding feature predicate is true, or if at least one element
   of the corresponding fpred-bag is true. The element yields its
   false-degradation factor otherwise.


(next page on part 2)

Next Section