2004/id/draft-holtman-http-negotiation-02.txt

Internet-Draft                                          Koen Holtman/TUE
Expires: February 14, 1997                               August 14, 1996


                 Transparent Content Negotiation in HTTP

                  draft-holtman-http-negotiation-02.txt


STATUS OF THIS MEMO


        This document is an Internet-Draft. Internet-Drafts are
        working documents of the Internet Engineering Task Force
        (IETF), its areas, and its working groups. Note that other
        groups may also distribute working documents as
        Internet-Drafts.

        Internet-Drafts are draft documents valid for a maximum of
        six months and may be updated, replaced, or obsoleted by
        other documents at any time. It is inappropriate to use
        Internet-Drafts as reference material or to cite them other
        than as "work in progress".

        To learn the current status of any Internet-Draft, please
        check the "1id-abstracts.txt" listing contained in the
        Internet-Drafts Shadow Directories on ftp.is.co.za
        (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
        Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
        West Coast).

        Distribution of this document is unlimited.  Please send
        comments to the HTTP working group at
        <http-wg@cuckoo.hpl.hp.com>.  Discussions of the working
        group are archived at
        <URL:http://www.ics.uci.edu/pub/ietf/http/>.  General
        discussions about HTTP and the applications which use HTTP
        should take place on the <www-talk@w3.org> mailing list.


ABSTRACT

        HTTP allows one to put multiple versions of the same
        information under a single URL.  Transparent content
        negotiation is a 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.

        Design goals for transparent content negotiation include low
        overhead on the request message size, downwards compatibility,
        extensibility, enabling the rapid introduction of new areas of
        negotiation, scalability, low cost of minimal support, end
        user control, and good cachability.


TABLE OF CONTENTS

     1 Introduction
      1.1 Background
      1.2 Note for readers

     2 Terminology
      2.1 Terms from HTTP/1.1
      2.2 New terms

     3 Notation

     4 Overview
      4.1 Content negotiation
      4.2 HTTP/1.0 style negotiation scheme
      4.3 Transparent content negotiation scheme
      4.4 Optimizing the negotiation process
      4.5 Retrieving a variant by hand
      4.6 Dimensions of negotiation
      4.7 Feature negotiation

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

     6 Feature negotiation
      6.1 Feature tags
      6.2 Accept-Features header
      6.3 Feature predicates
      6.4 Features attribute

     7 Feature negotiation examples
      7.1 Use of feature tags
      7.2 Use of numeric feature tags

     8 Feature tag registration
      8.1 Evolution of feature tags
      8.2 Core set of feature tags
      8.3 Feature tag design

     9 Content negotiation response codes and headers
      9.1 506 Variant Also Negotiates
      9.2 Accept-Features
      9.3 Content-Features
      9.4 Alternates
      9.5 Alternates-Older
      9.6 Negotiate
      9.7 Variant-Vary

     10 Content negotiation responses
      10.1 List response
      10.2 Choice response
       10.2.1 Construction by origin servers
       10.2.2 Construction by proxies
      10.3 Reusing the Alternates header
      10.4 Extracting a normal response from a choice response
      10.5 Elaborate Vary headers
       10.5.1 Construction of an elaborate Vary header
       10.5.2 Caching of an elaborate Vary header

     11 The network negotiation algorithm
      11.1 Input
      11.2 Output
      11.2.1 Output for proxies
      11.2.2 Output for origin servers
      11.2.3 Output for user agents
      11.3 Computing the overall quality values
      11.4 Definite and speculative quality values
      11.5 Determining the result
      11.5.1 Result for proxies and origin servers
      11.5.2 Result for user agents
      11.6 Construction of short requests

     12 User agent support for transparent negotiation
      12.1 Handling of responses
      12.2 Presentation of a transparently negotiated resource

     13 Origin server support for transparent negotiation
      13.1 Requirements
      13.2 Negotiation on transactions other than GET and HEAD

     14 Proxy support for transparent negotiation

     15 Security and privacy considerations
      15.1 Accept headers revealing information of a private nature
      15.2 Spoofing of responses from variant resources

     16 Acknowledgments

     17 References

     18 Author's address

     19 Appendices
      19.1 Adding an Expires header to ensure HTTP/1.0 compatibility
      19.2 Origin server implementation considerations
      19.2.1 Implementation with a CGI script
      19.2.2 Direct support by the HTTP server
      19.2.3 Negotiable content authoring
      19.3 Open issues in transparent content negotiation
      19.4 Other negotiation specifications
      19.4.1 User-Agent Display Attributes Headers
      19.4.2 PEP: An Extension Mechanism for HTTP/1.1
      19.5 Related issues
      19.5.1 Current negotiation practice
      19.5.2 Bandwidth negotiation
      19.5.3 Content transformation by proxies


1  Introduction

   HTTP allows one to put multiple versions of the same
   information under a single URI.  Each of these versions is called a
   `variant'.  Transparent content negotiation is a mechanism, layered
   on top of the HTTP/1.1 protocol [1], 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.

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


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,
       allowing graceful evolution of the web

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

     * ability to offer good service to a wider range of browsing
       platforms (from low-end PDA's to high-end VR setups)

     * elimination of the need for error-prone and cache-unfriendly
       User-Agent based negotiation

     * ability to construct sites without `click here for the X
       version' links

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

   Nevertheless, the development of content negotiation has been a
   slow process, maybe because the expected benefits are mostly
   long-term benefits.  Also, all immediately obvious content
   negotiation solutions involve the sending of larger HTTP request
   messages.  Larger request messages are unacceptable to many people:
   a small overhead on the request size is often cited as the main
   technical requirement for any scheme which offers the above
   benefits.

   Therefore, a low overhead on the request message size is one of the
   main design goals of this specification; a large fraction of the
   text below is devoted to the definition of mechanisms for meeting
   this design goal.  The desire to provide for good cachability in
   all cases accounts for another considerable part of the size of
   this document.

   Other design goals include downwards compatibility, extensibility,
   enabling the rapid introduction of new areas of negotiation,
   scalability, low cost of minimal support, and end user control.
   End user control, the option to manually retrieve other variants if
   desired, is the one redeeming quality of the `click here for the X
   version' type of negotiation, and it is considered important that
   this option is preserved.


1.2 Note for readers

   Some sections in this document discuss requirements for proxy
   caches only.  Implementers of origin servers and user agents (but
   not implementers of user agent caches) can skip these sections.
   The sections which can be skipped are:

       9.5 Alternates-Older
       9.7 Variant-Vary
       10.2.2 Choice response construction by proxies
       10.3 Reusing the Alternates header
       10.4 Extracting a normal response from a choice response
       10.5.2 Caching of an elaborate Vary header
       14 Proxy support for transparent negotiation

   The skipping of these sections is also recommended on first
   reading.


2  Terminology

2.1 Terms from HTTP/1.1

   This specification mostly uses the terminology of the HTTP/1.1
   specification [1].  The definitions below were reproduced 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.

   variant
     A resource may have one, or more than one, representation(s)
     associated with it at any given instant.  Each of these
     representations is termed a `variant.'  Use of the term `variant'
     does not necessarily imply that the resource is subject to
     content negotiation.

   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.

   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.

   first-hand
     A response is first-hand if it comes directly and without
     unnecessary delay from the origin server, perhaps via one or more
     proxies.  A response is also first-hand if its validity has just
     been checked directly with the origin server.

   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 which supports transparent content negotiation.  A
     transparently negotiable resource always has a variant list bound
     to it, usually represented as an Alternates header.

   variant list
     The list of variants bound to a transparently negotiable
     resource.

   variant description
     A machine-readable description of a variant, 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 simple GET request.

   list response
     A list response contains the variant list of the negotiable
     resource, but no variant data.  It is generated if the sever
     cannot or does not want to choose a particular best variant for
     the request.  List responses are defined in Section 10.1.

   choice response
     A choice response contains both the variant list of the
     negotiable resource, and a representation of the best variant for
     the request.  Choice responses are defined in Section 10.2.

   normal response
     A HTTP response which is not a list response or a choice
     response.  Normal responses are never generated by transparently
     negotiable resources, and are always generated by variant
     resources.

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

   network negotiation algorithm
     A standardized algorithm by which a party in the negotiation
     process can choose a best variant on behalf of another party.
     The algorithm computes if the Accept headers in the request
     contain sufficient information to allow a choice, and, if so,
     which variant must be chosen.  The network negotiation algorithm
     is defined in Section 11.

   neighbor
     Two resources are called neighbors if the absolute URI of the
     first resource up to its last slash equals the absolute URI of
     the second resource up to its last slash.  The neighboring
     relation is important because of security considerations, see
     Section 15.2.

   [##Historical note: In the context of old versions of the HTTP/1.1
   specification like [2], list responses can be called `pre-emptive
   negotiation responses', and choice responses can be called
   `reactive negotiation responses'.##]

   [##Note: In the context of the HTTP/1.1 specification [1], both
   list and choice responses are the result of server-driven
   negotiation, though a list response is a server-driven negotiation
   response meant to initiate agent-driven negotiation.##]


3  Notation

   The notation [## ... ##] in this document encloses an editorial
   comment.  Such a comment will be either removed or replaced by real
   text in the final version of this document.

   The version of BNF used in this document is taken from [1], and
   many of the nonterminals used are defined in [1].

   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 )


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 one 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

   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 will have multiple variants.


4.3 Transparent content negotiation scheme

   The transparent 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.html.en" 0.9 {type text/html} {language en}},
     {"paper.html.fr" 0.7 {type text/html} {language fr}},
     {"paper.ps.en"   1.0 {type application/postscript} {language en}}

   The syntax and semantics of the variant descriptions in this list
   are covered in depth 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:

      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.html.en
        |
         ---------------------------------- >         [normal response]
                return of html.en

   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, the information about capabilities and
   preferences is only used by the user agent itself.  Therefore, the
   sending of 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 depth 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 19:39:48 GMT
     Alternates: {"paper.html.en" 0.9 {type text/html} {language en}},
                 {"paper.html.fr" 0.7 {type text/html} {language fr}},
                 {"paper.ps.en"   1.0 {type application/postscript}
                     {language en}}
     Vary: *
     Content-Type: text/html
     Content-Length: 227

     <h2>Multiple Choices:</h2>
     <ul>
     <li><a href=paper.html.en>HTML, English version</a>
     <li><a href=paper.html.fr>HTML, French version</a>
     <li><a href=paper.ps.en>Postscript, English version</a>
     </ul>

   The HTML entity included in the response ensures compatibility with
   (existing) user agents which do not support transparent content
   negotiation.  Such user agents will ignore the computer-readable
   list in the Alternates header and just display the HTML entity,
   allowing the user to select the best variant by hand.


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 complete
   responses.  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.html.en
                     |
                  has the variant
                  in cache
                     |
                      -------------------------- >  [normal response]
                         return of html.en

   Second, the user agent can send small Accept headers which could
   allow a server to determine the choice the user agent would make on
   receiving the list.  If the Accept headers contain enough
   information, the origin server can send back the variant 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 html.en and list

   This choosing based on small accept headers can be done with the
   network negotiation algorithm (Section 11).  This algorithm takes
   the variant list and the Accept headers as input.  It computes if
   the Accept headers contain sufficient information to allow a choice
   on behalf of the user agent, and, if so, which variant must be
   chosen.

   The response in the above diagram is called a choice response: it
   transmits both the chosen variant and the list of all variants
   bound to the negotiable resource.  Choice responses are covered in
   depth in Section 10.2.  As an example, the choice response in the
   above picture could be:

     HTTP/1.1 200 OK
     Date: Tue, 11 Jun 1996 19:39:54 GMT
     Content-Type: text/html
     Content-Length: 5327
     Content-Location: paper.html.en
     Alternates: {"paper.html.en" 0.9 {type text/html} {language en}},
                 {"paper.html.fr" 0.7 {type text/html} {language fr}},
                 {"paper.ps.en"   1.0 {type application/postscript}
                     {language en}}
     Vary: *

     <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.html.en
                     |
                      ---------- >   [normal response]
                        html.en  |
                                  ---------------- >  [choice response]
                                   html.en and list

   Here, the proxy cache nearest to the user agent was able to use a
   cached variant list to choose on behalf of the user agent.


4.5 Retrieving a variant by hand

   If a transparently negotiated resource is accessed, the user agent
   will always at some point receive the list of available variants.
   The user agent can use this list to make available a menu (in HTML or
   not) which lists all variants and their characteristics to the user.
   Such a menu will allow the user to randomly browse other variants,
   and will also make it possible to manually correct any sub-optimal
   choice made by the automatic negotiation process.


4.6 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.  Transparent negotiation does not prohibit proxies to
   encode or decode a relayed or cached response on the fly: the
   response still contains the same variant as far as transparent
   content negotiation is concerned.


4.7 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 is the main 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'.


5  Variant descriptions

5.1 Syntax

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

       variant-descr =
               "{" <"> URI <">
                   source-quality
                   [ "{" "type" media-type "}" ]
                   [ "{" "charset" charset "}" ]
                   [ "{" "language"  1#language-tag "}" ]
                   [ "{" "length" 1*DIGIT "}" ]
                   [ "{" "features" feature-list "}" ]
                   [ "{" "description" quoted-string "}" ]
                   [ extension-attribute ]
                "}"

       source-quality = qvalue

       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 "}">

   Examples are

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

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

   The various attributes which can be present in a variant
   description are covered in the subsections below.


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
   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.

   It is important that content providers do not assign very low
   source quality values without good reason, as this would limit the
   ability of users to influence the negotiation process with their
   own preference settings.  The following table should be used as a
   guide when assigning source quality values:

       1.000       no degradation
       0.999-0.900 no noticeable degradation
       0.899-0.700 noticeable, but acceptable degradation
       0.699-0.500 barely acceptable degradation
       0.499-0.000 unacceptable degradation

   [##Issue to be resolved: can we come up with a word other than
   `degradation' that covers better the case of variants not converted
   from one source?##]

   When assigning source-quality values, content providers must not
   account for the size of the variant and its impact on transmission
   and rendering delays.  Source-quality values are assigned assuming
   instantaneous transmission and rendering.  This rule ensures that a
   future mechanism for bandwidth negotiation (see Appendix 19.5.2)
   can be cleanly added.


5.4 Type, language, length, and charset.

   The type, language, and length attributes of a variant description
   can carry the same information as their Content-* response header
   counterparts as defined in [1].  The counterpart of the charset
   attribute is the charset parameter which can be present in the
   Content-Type response header, for example

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

   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.

   The length attribute, if present, must reflect the length of the
   variant only, not the length of the variant plus the length of any
   objects inlined or embedded by the variant.

      Note: A server need not necessarily maintain a one-to-one
      correspondence between attributes in the description of a
      variant and the Content-* headers in responses containing that
      variant.  For example, if the variant description contains a
      language attribute, the response does not necessarily have to
      contain a Content-Language header, and 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 features 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 is meant to provide a textual description
   of the variant, to be displayed by a user agent when showing a menu
   of available variants (Section 12.2).  This attribute can be
   included if the URI and normal attributes of a variant are
   considered too opaque to allow interpretation by the user.


5.7 Extension-attribute

   The extension-attribute allows future specifications to
   incrementally define new dimensions of negotiation, and eases
   content negotiation experiments under HTTP/1.1.  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 the network
   negotiation algorithm if an unknown extension attribute is present
   in the variant list.


6  Feature negotiation

   Feature negotiation has been introduced in Section 4.7.  This
   section defines the feature negotiation mechanism, Section 7
   contains examples of its use.


6.1 Feature tags

   A feature tag (ftag) identifies a capability of a user agent or a
   preference of a user.  A feature is said to be `present' in a user
   agent if the corresponding capability is implemented, or if the
   user has expressed corresponding preference.

       ftag = 1*<any CHAR except CTLs or tspecials or "!">

       tspecials      = "(" | ")" | "<" | ">" | "@"
                      | "," | ";" | ":" | "\" | <">
                      | "/" | "[" | "]" | "?" | "="
                      | "{" | "}" | SP | HT

        (tspecials definition reproduced from [1])

   Examples are

        ns_tables, fonts, blebber, wolx, screenwidth, colordepth

   An example of the use of feature tags in a variant description is

     {"index.html" 1.0 {type text/html} {features ns_tables ns_frames}}

   Feature-tags are case-insensitive.  The definition of a feature tag
   may state that a feature tag, if present, must have associated with
   it a numeric value which reflects a particular capability or
   preference.  For example, a feature tag `screenwidth' could be
   present with a value of 640.

   Note that it sometimes depends on context whether a feature tag
   expresses a capability or a preference.  For a text-only browser,
   the `textonly' tag is naturally present, but the user of a
   graphical browser could set the tag to be present if text-only
   content is preferred to graphical content.

   As feature registration will 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 with tags unknown to it as absent.


6.2 Accept-Features header

   The Accept-Features request header can be used by a client to give
   information about the presence or absence of certain features.

       Accept-Features = "Accept-Features" : #( ftag
                                              | "!" ftag
                                              | ftag "=" number
                                              | "*"
                                              )

       number = 1*DIGIT

   An example is:

       Accept-Features: blex, !blebber, colordepth=5, *

   A feature tag must never occur twice in an Accept-Features header.
   In the Accept-Features header, an ftag without a "!"  indicates that
   the corresponding feature is present, but that is has no numeric
   value associated with it.  An ftag with a "!"  indicates that the
   corresponding feature is absent.  An ftag with a number indicates
   that the corresponding feature is present with the given numeric
   value.

   The special construct "*", if present, makes all true feature
   predicates (Section 6.3) on feature tags not present in the header.
   Absence of the Accept-Features header in a request is equivalent to
   the inclusion of

       Accept-Features: *


6.3 Feature predicates

   Feature predicates are used in the features attribute of a variant
   description.

      fpred = ( ftag )
            | ( "!" ftag )
            | ( ftag ">=" number )
            | ( ftag "<" number )

   Examples feature predicates are

      blebber, !blebber, colordepth>=5, blex<54

   The network negotiation algorithm can compute the truth value of a
   feature predicate by using the contents of the Accept-Features
   header of the current request.

   If the ftag in a feature predicate appears in the Accept-Features
   header, the truth value of the predicate is defined as follows,
   depending on its form:

      ftag     true if the feature is present according to the
               Accept-Features header, false otherwise.

      !ftag    true if the feature is absent according to the
               Accept-Features header, false otherwise.

      ftag>=N  true if the feature is present with a value greater than
               or equal to N according to the Accept-Features header,
               false otherwise.

      ftag<N   true if the feature is present with a value less than N
               according to the Accept-Features header, false otherwise.

      [##Issues to be resolved:  Add ftag<=N and ftag>N for symmetry?
      Add ftag=N?  Add ftag=N as a synonym for ftag>=N?##]

   If the ftag in a feature predicate does not appear in the
   Accept-Features header, the value of the predicate is true if there
   is a "*" in the Accept-Features header, false otherwise.

   As an example, the header

       Accept-Features: blex, !blebber, colordepth=5, !screenwidth, *

   makes the following predicates true:

       blex, colordepth>=4, colordepth<6, colordepth, !screenwidth,
       frtnbf, !frtnbf, frtnbf>=4, frtnbf<4

   and makes the following predicates false:

       !blex, blex>=0, blebber, colordepth>=6, !colordepth,
       screenwidth, screenwidth>=640, screenwidth<640


6.4 Features attribute

   The features attribute

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

   is used in a variant description to specify how the presence or
   absence of particular features 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   =  1*3DIGIT [ "." 0*3DIGIT ]
       false-degradation  =  1*3DIGIT [ "." 0*3DIGIT ]

   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.

   The network negotiation algorithm can 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.

   [##Issue to be resolved: It is unknown yet whether this features
   attribute definition makes the right tradeoff between complexity
   and (ease of) expressive power.  The attribute grammar above is
   designed to be parsable with simple non-recursive parsers.  The
   true-improvement construct does not add expressive power in a
   theoretical sense, but does make the (automatic) construction of
   variant lists more straightforward in many cases.##]

   [##Aside for mathematicians: note the similarity between the
   feature-list

            [f1 !f2] [!f1 f3]

   and the conjunctive normal form of a boolean expression.  This
   similarity implies good things about the expressive power of the
   features attribute.  I have not yet explored how far this power
   extends into the non-boolean domain.##]


7  Feature negotiation examples

   This section contains examples of the use of feature tags in
   variant descriptions.

   [##Note: A future version of this document will probably revise and
   extend this section.##]


7.1 Use of feature tags

   Feature tags can be used in variant lists to express the quality
   degradation associated with the presence or absence of certain
   features.  One example is

     {"index.html.plain" 0.7 },
     {"index.html"       1.0 {features ns_tables ns_frames}}

   Here, the "{features ns_tables ns_frames}" part expresses that
   index.html uses the features tagged as ns_tables and ns_frames.  If
   these features are absent, the overall quality of index.html degrades
   to 0.  Another example is

     {"home.graphics" 1.0 {features !textonly}},
     {"home.textonly" 0.7 }

   where the "{features !textonly}" part expresses that home.graphics
   requires the absence of the textonly feature.  If the feature is
   present, the overall quality of home.graphics degrades to 0.

   The absence of a feature need not always degrade the overall quality
   to 0.  In the example

     {"x.html.1" 1.0 {features fonts/0.7}}

   the absence of the fonts feature degrades the quality with a factor
   of 0.7.  "fonts/0.7" can be pronounced as "fonts, or a degradation of
   0.7".  In the example

     {"x.html.2" 0.5 {features fonts:1.5}}

   the presence of the fonts feature improves the overall quality with a
   factor of 1.5. If the fonts feature is absent, the overall quality is
   not affected.  "fonts:1.5" can be pronounced as "fonts improves with
   1.5".  Finally, in the example

      {"y.html" 1.0 {features [blebber wolx] }}

   The "[blebber wolx]" expresses that y.html requires the presence of
   the blebber feature or the wolx feature.  This construct can be
   used in a number of cases:

     1. blebber and wolx actually tag the same feature, but they
        were registered by different people, and some browsers say
        they support blebber while others say they support wolx.

     2. blebber and wolx are HTML tags of different vendors which
        implement the same functionality, and which were used
        together in y.html without interference.

     3. blebber and wolx are HTML tags of different vendors which
        implement the same functionality, and y.html uses conditional
        HTML to provide versions using both tags [##Note: conditional
        HTML does not yet exist, but it is something people are thinking
        about.##]

     4. blebber is a complicated HTML tag with only a sketchy
        definition, implemented by one browser vendor, and wolx
        indicates implementation of a well-defined subset of the blebber
        tag by some other vendor(s).  y.html uses only this well-defined
        subset.


7.2 Use of numeric feature tags

   As an example of negotiation in a numeric area, the following variant
   list describes four variants with title graphics designed for
   increasing screen widths:

     {"home.pda"    1.0 {features screenwidth<200}},
     {"home.narrow" 1.0 {features screenwidth>=200 screenwidth<600}},
     {"home.normal" 1.0 {features screenwidth>=600 screenwidth<1000}},
     {"home.wide"   1.0 {features screenwidth>=1000}}

   The above variant list has a serious problem, however: a user agent
   not supporting screenwidth negotiation is given no guidance on
   which variant to select.  For such a user agent, the absence of the
   screenwidth feature would degrade the overall quality of each
   variant to 0.  A variant list which solves this problem is

     {"home.pda"    1.0 {features screenwidth<200}},
     {"home.narrow" 1.0 {features screenwidth>=200 screenwidth<600}},
     {"home.normal" 0.95 },
     {"home.wide"   1.0 {features screenwidth>=1000}}

   With this list, a user agent which does not support the screenwidth
   feature will always select the home.normal variant.  A user agent
   which does support the screenwidth feature will only select the
   home.normal variant if its screen width is in the range 600..999.


8  Feature tag registration

   [##A specification of the feature tag registration process has not
   yet been completed.  This issue has yet to be discussed by the
   http-wg.##]

   [##According to current plans, everybody will be allowed to register
   feature tags: registration only requires that the tag follows the
   syntax rules, and that a definition of the meaning of the tag is
   supplied.  In particular, registration will not require actual
   implementation of a feature, and there will be no test on whether the
   feature definition overlaps with another feature definition.##]

   [##It is unclear yet whether it is desirable for feature tags to
   have some hierarchical structure, which would make it easier, for
   example, to trace who registered the feature.  All that is known
   now is that it is desirable to have short feature tags.  A naming
   scheme like that for SGML-DTDs would probably yield feature tags
   which are too long.  The main advantage of having a registration
   process at all is that it allows for short tags without running the
   risk of `tag collision'.##]


8.1 Evolution of feature tags

   The feature negotiation mechanism is designed not to break if 1000+
   features, partially overlapping, are registered.  This allows for
   feature tag creation to be an evolutionary process, in which many
   tags are created while only a few `survive' to become generally
   used.

   As the development of new web content formats is currently in an
   evolutionary phase, rather than a standardization phase, it is
   thought that this evolutionary approach to feature tag creation has
   the best chances of keeping up with new developments.

   It is expected that after the introduction of feature negotiation,
   an explosion in feature tag registration will occur, and that only
   some of these tags will end up being actively used to label
   variants.  Web indexing robots could, while traversing the web,
   gather statistics about actual use of feature tags.  These
   statistics could be used by individuals to compile lists, intended
   for content authors, of useful feature tags for particular areas of
   negotiation.  Note that this indexing activity is orthogonal to the
   feature registration process.  It is expected that, once an area of
   negotiation is well-understood, this process will converge on a
   commonly-used and commonly-recognized set of feature tags for that
   area.


8.2 Core set of feature tags

   [##In order to jump-start feature negotiation, it seems useful to
   define a `core set' of feature tags in a separate document.  These
   feature tags would cover the areas of negotiation which are
   currently well understood, like negotiation on currently stable
   HTML extensions.  The transparent content negotiation specification
   could then require (or strongly encourage) that user agents
   implementing transparent content negotiation must recognize (not
   support!) all tags in the core set.

   The core set could be defined in a non-standards track document
   which would be completed along with this document.##]


8.3 Feature tag design

   When designing a new feature tag, it is important to take into
   account that existing user agents, which will not recognize the new
   tag, will treat the feature as absent.  In general, a new feature
   tag needs to be designed in such a way that absence of the tag is
   the default case which reflects current practice.  If this design
   principle is ignored, the resulting feature tag will generally be
   unusable.

   As an example, one could try to support negotiation between
   monochrome and color content by introducing a `color' feature tag,
   the presence of which would indicate the capability to display
   color graphics.  However, if this new tag is used in a variant
   list, for example

      {"rainbow.gif"      1.0 {features color} }
      {"rainbow.mono.gif" 0.6 {features !color}}

   then existing user agents, which would not recognize the color tag,
   would all display the monochrome rainbow.  The color tag is
   therefore unusable in situations where optimal results for existing
   user agents are desired.  To provide for negotiation in this area,
   one needs to introduce a `monochrome' feature tag, the presence of
   which indicates that the user agent can only render monochrome
   graphics.


9  Content negotiation response codes and headers

   This specification adds one new response code to those defined in
   HTTP/1.1 [1].  This is a 5xx (Server Error) class response.  It
   also adds six new headers.


9.1 506 Variant Also Negotiates

   The server has an internal configuration error: the chosen variant
   resource is configured to engage in transparent content negotiation
   itself, and is therefore not a proper end point in the negotiation
   process.


9.2 Accept-Features

  This request header was defined in Section 6.2.


9.3 Content-Features

   The Content-Features response header can be used by a server to
   indicate how the presence or absence of particular features in the
   user agent affects the overall quality of the response.

       Content-Features = "Content-Features" ":" feature-list


9.4 Alternates

   The Alternates response header is used to convey the list of
   variants bound to a negotiable resource in a response, and can also
   contain other directives for the content negotiation process.

       Alternates = "Alternates" ":" 1#( variant-descr
                                       | alternates-directive )

       alternates-directive = ( "max-age" "=" delta-seconds )
                            | ( "min-q"   "=" short-float )
                            | "forward"
                            | extension-alternates-directive

       delta-seconds  = 1*DIGIT

       short-float = 1*3DIGIT [ "." 0*3DIGIT ]

       extension-alternates-directive =
                              token [ "=" ( token | quoted-string ) ]

   An example is

     Alternates: {"paper.html.en" 0.9 {type text/html} {language en}},
                 {"paper.html.fr" 0.7 {type text/html} {language fr}},
                 {"paper.ps.en"   1.0 {type application/postscript}
                     {language en}},
                 min-q=0.4

   Any relative URI specified in a variant-descr field is relative to
   the request-URI.  The max-age directive, if present, specifies the
   freshness lifetime of the information in the Alternates header.
   The min-q and forward directives, if present, can influence
   decisions made by the network negotiation algorithm on behalf of
   the origin server.  Clients should ignore all
   extension-alternates-directives they do not understand.

   [##Question to be resolved: should this header be called
   `Variants'?  Probably not, the 1.1 spec already announced that it
   would be called `Alternates'.##]


9.5 Alternates-Older

   The Alternates-Older response header conveys an estimate of the age
   difference between the Alternates header contained in a choice
   response and the variant data contained in the response.  The age
   is measured as the time since generation or revalidation at the
   origin server, as in the HTTP/1.1 specification [1].

       Alternates-Older = "Alternates-Older" ":" signed-delta-seconds

       signed-delta-seconds  = [ "-" ] 1*DIGIT

   A positive value means that the Alternates header is older, a
   negative value means that the Alternates header is less old.  If
   the Alternates-Older header is absent, it is known or estimated
   that there is no age difference between the Alternates header and
   the variant data.  An example is

      Alternates-Older: 5433

   This header is important for proxies which negotiate using cached
   variant lists, see Section 10.3.  Only negotiating proxies need to be
   able to construct Alternates-Older headers, see Section 10.2.2.

   [##Note: The age of the Alternates header cannot be conveyed in an
   Alternates-Age header, because plain HTTP/1.1 caching proxies would
   only update the Age header, not the Alternates-Age header, when
   serving a choice response from cache memory.##]


9.6 Negotiate

   The Negotiate request header can contain directives for any content
   negotiation process initiated by the request.  Presence of this
   header indicates that the user agent supports transparent content
   negotiation for the current request.

      Negotiate = "Negotiate" ":" #negotiate-directive

      negotiate-directive = token [ "=" ( token | quoted-string ) ]

   An example is

      Negotiate:

   This specification does not define any negotiate-directives, this
   is left to future extensions.  Servers should ignore all
   negotiate-directives they do not understand.  The presence or
   absence of a Negotiate header in a request is significant in
   calculations performed by the network negotiation algorithm.

   [#Question to be resolved: is it safer to put a keyword in the
   negotiate header to signal transparent negotiation capability?
   Some cache implementations might treat an empty Negotiate header
   the same as an absent Negotiate header under Vary: negotiate.  Is
   the 1.1 spec clear enough on this?##]


9.7 Variant-Vary

   The Variant-Vary response header can be used in a list response to
   record any vary information which applies to the variant data
   contained in the response, rather than to the response as a whole.

      Variant-Vary  = "Variant-Vary" ":" ( "*" | 1#field-name )

   Use of the Variant-Vary header is discussed in Section 10.2.1.


10 Content negotiation responses

   A request on a transparently negotiated resource can yield two
   types of non-error responses: list responses and choice responses.
   A list response contains only the list of variants bound to the
   negotiable resource, and is generated if the sever cannot or does
   not want to choose a particular best variant for the request.  A
   choice response contains both the list and a representation of the
   best variant.

   Normal responses are non-error responses generated by requests on
   resources which are not transparently negotiated.  A normal
   response never contains an Alternates header, a list or choice
   response always contains an Alternates header.  A list response
   always has the 300 (Multiple Choices) status code, a choice
   response never has the 300 status code.


10.1 List response

   A list response has the 300 response status code, and must contain,
   besides the normal headers required by HTTP, the Alternates header
   bound to the negotiable resource, a Vary header and, unless it was
   a HEAD request, an entity body which allows the user to manually
   select the best variant.

   An example a list response is:

     HTTP/1.1 300 Multiple Choices
     Date: Tue, 11 Jun 1996 20:02:21 GMT
     Alternates: {"paper.html.en" 0.9 {type text/html} {language en}},
                 {"paper.html.fr" 0.7 {type text/html} {language fr}},
                 {"paper.ps.en"   1.0 {type application/postscript}
                     {language en}}, max-age=86400
     Vary: negotiate, accept, accept-language
     Etag: "gonkyyyy"
     Cache-control: max-age=86400
     Content-Type: text/html
     Content-Length: 227

     <h2>Multiple Choices:</h2>
     <ul>
     <li><a href=paper.html.en>HTML, English version</a>
     <li><a href=paper.html.fr>HTML, French version</a>
     <li><a href=paper.ps.en>Postscript, English version</a>
     </ul>

   Note that the same max-age value appears both in the Alternates
   header and in the Cache-Control header.

   The Vary header in the response should ensure correct handling by
   HTTP/1.1 caching proxies not capable of transparent content
   negotiation.  This header can either be

        Vary: *

   or a more elaborate header, see Section 10.5.1.

   Only the origin server may construct list responses.  List
   responses are cachable unless indicated otherwise.  A proxy may
   reuse a list response as a whole if the response is fresh in the
   sense of the HTTP/1.1 specification [1], even if the Alternates
   header in the response is no longer fresh by itself.

   According to the HTTP/1.1 specification [1], a user agent not
   capable of transparent content negotiation will, when receiving a
   list response, display the entity body included in the response.
   If the response contains a Location header, however, the user agent
   may automatically redirect to this location.

   The handling of list responses by clients supporting transparent
   content negotiation is described in Sections 12.1 and 14.

   [##Issue to be resolved: Some existing HTTP/1.0 user agents crash
   when getting a 300 response without a Location header.  This
   problem may be big enough to warrant the allocation of an extra
   list response code outside of the 3xx class for possible use in
   responses to HTTP/1.0 clients.##]


10.2 Choice response

   A choice response merges a normal HTTP response from the chosen
   variant with a Content-Location header giving the location of the
   variant, and the Alternates and Vary headers bound to the
   negotiable resource.

   The cachability of a choice response as a whole is defined in the
   HTTP/1.1 specification [1].  Depending on the response code, a
   choice response as a whole is either cachable unless indicated
   otherwise, or uncachable.

10.2.1 Construction by origin servers

   Origin servers must construct choice responses with the
   following algorithm, or any other algorithm which gives equal
   results.

     1. Construct a HTTP request message on the best variant resource
        by rewriting the request-URI and Host header (if appropriate)
        of the received request message on the negotiable resource.

     2. Generate a valid HTTP response message for the request message
        constructed in step 1.

     3. Check for an internal server configuration error. If the HTTP
        response message generated in step 2 contains an Alternates
        header, a Content-Location header, or has the 300 status code,
        then the best variant resource is not a proper end point in
        the negotiation process, and a 506 (Variant Also Negotiates)
        error response message should be generated instead of going to
        step 4.

     4. Add a number of headers to the HTTP response message generated
        in step 2.

        a. Add a Content-Location header giving the location of the
           chosen variant.

               Note: According to the HTTP/1.1 specification [1], if
               the Content-Location header contains a relative URI,
               this URI is relative to the URI in the Content-Base
               header, if present.

        b. If any Vary headers are present in the response message
           from step 2, add, for every Vary header, a Variant-Vary
           header with a copy of the contents of this Vary header.

        c. Add the Alternates header bound to the negotiable resource.

        d. Add a Vary header to ensure correct handling by HTTP/1.1
           caching proxies not capable of transparent content
           negotiation.  This header can either be

               Vary: *

           or a more elaborate header, see Section 10.5.1.

        e. To ensure compatibility with HTTP/1.0 caching proxies which
           do not recognize the Vary header, an Expires header with a
           date in the past may be added. See Appendix 19.1 for more
           information.

   An example of a choice response generated by an origin server is:

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

     <title>A paper about ....


10.2.2 Construction by proxies

   Proxies must construct choice responses with the following
   algorithm, or any other algorithm which gives equal results.

     1. Same as in Section 10.2.1.

     2. Obtain a fresh or first-hand HTTP response message for the
        request message constructed in step 1.  The message can be
        obtained from cache memory, or by passing the constructed HTTP
        request message towards the origin server.

     3. Same as in Section 10.2.1.

     4. Add a number of headers to the HTTP response message generated
        in step 2.

        a. Same as in Section 10.2.1.

        b. Same as in Section 10.2.1.

        c. Add a fresh or first-hand Alternates header bound to the
           negotiable resource.  Section 10.3 specifies how this
           header can be obtained.

        d. Add a Vary header to ensure correct handling by HTTP/1.1
           caching proxies not capable of transparent content
           negotiation.  This header can either be

               Vary: *

           or a more elaborate fresh or first-hand header,
           Section 10.5.2 specifies how this header can be obtained.

        e. Same as in Section 10.2.1.

        f. Compute the age difference between the Alternates header
           in the response in the following way.

           - Let variant_age be the age of the response obtained in
             step 2, calculated according to the rules in the HTTP/1.1
             specification [1]. If the response is known to be
             first-hand, variant_age can be 0.

           - Let alternates_age be the age of the Alternates header
             added in step c, calculated according to the rules in
             Section 10.3, or 0 if the Alternates header is known to
             be first-hand.

           - Compute the age difference:

               alternates_older = alternates_age - variant_age

           If the computed alternates_older value is greater than 0,
           an Alternates-Older header with this value must be added to
           the response.  If the value is 0, an Alternates-Older
           header with this value need not be added.  If the value is
           less than 0, an Alternates-Older header with this value
           should be added.

   An example of a choice response which could be sent by a caching
   proxy is:

     HTTP/1.1 200 OK
     Date: Tue, 11 Jun 1996 20:05:31 GMT
     Content-Type: text/html
     Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
     Etag: "497542"
     Cache-control: max-age=604800
     Content-Length: 5327
     Age: 432000
     Content-Location: paper.html.en
     Alternates: {"paper.html.en" 0.9 {type text/html} {language en}},
                 {"paper.html.fr" 0.7 {type text/html} {language fr}},
                 {"paper.ps.en"   1.0 {type application/postscript}
                     {language en}}, max-age=86400
     Vary: negotiate, accept, accept-language
     Alternates-Older: -410400
     Expires: Thu, 01 Jan 1980 00:00:00 GMT

     <title>A paper about ....

   Here, the age of the variant data is 432000 seconds (5 days), while
   the age of the Alternates header is 432000 + -410400 = 21600
   seconds (6 hours).


10.3 Reusing the Alternates header

   Proxy caches may extract and cache the Alternates header in any
   cachable list or choice response.  If the Alternates header is
   fresh or first-hand, it may be reused to negotiate on behalf of the
   user agent or origin server (Section 14) and to construct choice
   responses (Section 10.2.2).  The freshness of an Alternates header
   is determined in the following way.

     - Let response_age be the current age of the response from which
       the header was extracted, calculated according to the rules in
       the HTTP/1.1 specification [1].

     - Let alternates_older be the value in the Alternates-Older
       header of this response, or 0 if no Alternates-Older header is
       present.

     - Let max_age be the value of the max-age directive in the
       Alternates header, or positive infinity if a max-age directive
       is absent.

   The age of the alternates header is

       alternates_age = response_age + alternates_older .

   The Alternates header is fresh if

       alternates_age < max_age .

   An Alternates header is fist-hand if it is used, without unnecessary
   delay, after being extracted from a first-hand response.


10.4 Extracting a normal response from a choice response

   If a proxy receives a choice response, it may extract and cache the
   normal HTTP response contained therein.  The normal response can be
   extracted by taking a copy of the choice response and then deleting
   the Content-Location, Alternates, Vary, and Alternates-Older
   header, and renaming any Variant-Vary headers to Vary headers.

   [##Question to be resolved: A method to get rid of the Expires
   header which could have been added in a step 4.e of Section 10.2.1
   and 10.2.2 could be invented.  Should such a method be added to
   this specification?  Probably not.##]

   This normal response may then be cached (as a HTTP response to the
   variant request as constructed in step 1. of Section 10.2.1) and
   reused to answer future direct requests on the variant resource
   according to the rules in the HTTP/1.1 specification [1].  This
   caching of extracted responses can increase overall efficiency with
   up to a factor 2.

   For security reasons (see Section 15.2), an extracted normal
   response may only be cached if the negotiable resource and the
   variant resource are neighbors.  If they are not neighbors, the
   proxy should reject the choice response as a probable spoofing
   attempt and pass on a 502 (bad gateway) error response instead.


10.5 Elaborate Vary headers

   The Vary header added to a list or choice response should ensure
   correct handling by HTTP/1.1 caching proxies not capable of
   transparent content negotiation.  The most simple Vary header which
   satisfies this requirement is

       Vary: *

   A more elaborate Vary header can be used to allow for certain
   optimizations which could be performed by some HTTP/1.1 caches
   which are not capable of transparent content negotiation, but which
   do cache multiple variants of one resource based on Vary header
   contents.

10.5.1 Construction of an elaborate Vary header

   Origin servers can construct a more elaborate Vary header in the
   following way.  First, start with the header

       Vary: negotiate

   Then, if any of the following attributes is present in any variant
   description in the Alternates header, add the corresponding header
   name to the Vary header

         attribute  |   header name to add
         -----------+---------------------
          type      |   accept
          charset   |   accept-charset
          language  |   accept-language
          features  |   accept-features

   The Vary header constructed in this way specifies the response
   variation which can be caused by the use of the network negotiation
   algorithm in proxies.  If the origin server uses a custom
   negotiation algorithm which takes additional headers (for example
   User-Agent) into account, these should also be added to the Vary
   header.

10.5.2 Caching of an elaborate Vary header

   Proxy caches cannot construct elaborate Vary headers by themselves,
   because they may not assume that the origin server uses the
   standard network negotiation algorithm to vary its responses.
   However, when extracting an Alternates header from a response
   (Section 10.3) caches may also extract the Vary header in the
   response, and reuse it along with the Alternates header.  A clean
   Vary header can however only be extracted if the variant does not
   vary itself, i.e. if a Variant-Vary header is absent.


11 The network negotiation algorithm

   The network negotiation algorithm is a standardized algorithm by
   which a party in the negotiation process can make a choice on
   behalf of another party.  For example, a proxy could choose a
   particular variant on behalf of the user agent in order to speed up
   the negotiation process by cutting corners (see Section 4.4).

   General principles underlying the network negotiation algorithm are
   as follows.

    - When running on an origin server or proxy, the algorithm will
      usually only have partial user agent capabilities and
      preferences information as input.  Therefore, instead of a
      choice for a best variant, the algorithm can also yield an
      `insufficient data, cannot choose' result.

    - Decisions are always made on either on behalf of the user agent
      or on behalf of the origin server.  They are made on behalf of
      the user agent if the user agent indicates that it is capable of
      transparent content negotiation, and on behalf of the origin
      server otherwise.

    - By including an Alternates header in the response, the origin
      server gives upstream proxies the permission to perform actions
      prescribed by the network negotiation algorithm instead of
      actions prescribed by the plain HTTP specification.

    - It is expected that user agents will use the network negotiation
      algorithm by default, locally supplying their complete
      capabilities and preferences to the algorithm, but this is not
      required.  User agents may use customized negotiation algorithms
      to automatically choose a variant.  Such algorithms could for
      example account for cross-dependencies between dimensions of
      negotiation.

   Note that in this specification, `use of the network negotiation
   algorithm' means use of any algorithm which yields equal results.


11.1 Input

   The algorithm is always executed for a particular request on a
   particular transparently negotiable resource.  It takes the
   following information as input.

    1. The list of variants of the resource, as present in the
       Alternates header of the resource.

    2. Any "min-q" and "forward" directives pertaining to the
       negotiation process, as specified by the Alternates header of
       the resource.

    3. (Partial) Information about capabilities and preferences of the
       user agent for this particular request, as given in the Accept
       headers of the request, or, if the algorithm runs on a user
       agent, as given by the internal capabilities and preferences
       database.

    4. A boolean indicating whether or not the user agent is capable
       of transparent content negotiation for this request.  (True if
       the request includes a Negotiate header, false otherwise).


11.2 Output

   As its output, the network negotiation algorithm and will yield the
   appropriate action to be performed.  Actions have labels `ACT_UA'
   for actions performed on behalf of the user agent, and `ACT_OS' for
   actions performed on behalf of the origin server.

11.2.1 Output for proxies

   If the algorithm runs on a proxy, there are five different possible
   results.  The first two results can be generated if the user agent
   is capable of transparent content negotiation:

      Choice_UA

        Choice on behalf of the user agent. The best variant may be
        retrieved and returned in a choice response.

      List_UA

        No choice possible, return the list.  The Accept headers do
        not contain sufficient information to make a choice on behalf
        of the user agent possible.  A list response should be
        returned, allowing the user agent to make the choice itself.

   The following results can be generated if the user agent is not
   capable of transparent content negotiation:

      Choice_OS

        Choice on behalf of the origin server.  The best variant may
        be retrieved and returned in a choice response.

      List_OS

        No choice possible, return the list.  The Accept headers do
        not contain sufficient information to make a choice on behalf
        of the origin server possible.  A list response should be
        returned, allowing the user to manually select the best
        variant.

      Forward_OS

        No choice possible, forward request towards the origin
        server. The Accept headers do not contain sufficient
        information to make a choice on behalf of the origin server
        possible. The request should be forwarded towards the origin
        server so that it can choose the most appropriate action with
        a custom negotiation algorithm.

11.2.2 Output for origin servers

   If the algorithm runs on an origin server, all results above,
   except Forward_OS, are possible, with the same interpretations.

11.2.3 Output for user agents

   If the algorithm runs on a user agent, only the results List_UA and
   Choice_UA are possible, with the following interpretations.

      Choice_UA

        Automatic choice. A particular variant X must be retrieved and
        displayed.

      List_UA

        No automatic choice possible, none of of the variants can be
        rendered according to the preferences and capabilities
        database.  An appropriate action like showing an error message
        with the list of variants to the user must be performed.


11.3 Computing the overall quality values

   As a first step in the network negotiation algorithm, the overall
   qualities of the individual variants in the list are computed.

   The overall quality Q of a variant is the value

      Q = qs * qt * qc * ql * qf

   where the factors qs, qt, qc, ql, and qf are determined as follows.

      qs Is the source quality factor in the variant description.

      qt The media type quality factor is 1 if there is no type
         attribute in the variant description, or if there is no
         Accept header in the request.  Otherwise, it is the quality
         assigned by the Accept header to the media type in the type
         attribute.

           Note: If a type is matched by none of the elements of an
           Accept header, the Accept header assigns the quality factor
           0 to that type.

      qc The charset quality factor is 1 if there is no charset
         attribute in the variant description, or if there is no
         Accept-Charset header in the request.  Otherwise, the charset
         quality factor is the quality assigned by the Accept-Charset
         header to charset in the charset attribute.

           Note: If a charset does not appear in an Accept-Charset
           header, the Accept-Charset header assigns the quality
           factor 0 to that charset.

      ql The language quality factor is 1 if there is no language
         attribute in the variant description, or if there is no
         Accept-Language header in the request.  Otherwise, the
         language quality factor is the highest quality factor
         assigned by the Accept-Language header to any one of the
         languages listed in the language attribute.

      qf The features quality factor is 1 if there is no features
         attribute in the variant description, or if there is no
         Accept-Features header in the request.  Otherwise, it is
         the feature negotiation quality degradation value for the
         features attribute, see Section 6.4.

   As an example, if a variant list contains the variant description

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

   and if the request contains the Accept headers

     Accept: text/html:q=1.0, */*:q=0.8
     Accept-Language: en;q=1.0, fr;q=0.5

   the network negotiation algorithm will compute an overall quality
   for the variant as follows:

     {"paper.html.en" 0.7 {type text/html} {language fr}}
                       |           |                 |
                       |           |                 |
                       V           V                 V
                      0.7   *     1.0        *      0.5  = 0.35

   With the above Accept headers, the complete variant list

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

   would yield the following computations:

                     qs  * qt  * qc  * ql  * qf  =  Q
                     ---   ---   ---   ---   ---   ----
      paper.html.en: 0.9 * 1.0 * 1.0 * 1.0 * 1.0 = 0.9
      paper.html.fr: 0.7 * 1.0 * 1.0 * 0.5 * 1.0 = 0.35
      paper.ps.en:   1.0 * 0.8 * 1.0 * 1.0 * 1.0 = 0.8


11.4 Definite and speculative quality values

   An overall quality value computed by an origin server or proxy can
   be either definite or speculative.

   An overall quality value for a variant is definite if it was
   computed without using any wildcard characters '*' in the Accept
   headers, and without the need to use the absence of a particular
   Accept header.  An overall quality value is speculative otherwise.

   As an example, in the previous section, the quality values of
   paper.html.en and paper.html.fr are definite, and the quality value
   of paper.ps.en is speculative because the type
   application/postscript was matched to the range */*.

   Definiteness can be defined more formally as follows.  An overall
   quality value Q is definite if the same quality value Q could be
   computed after the request message is changed in the following way:

       1. If an Accept, Accept-Charset, Accept-Language, or
          Accept-Features, header is missing from the request, add
          this header with an empty field.

       2. Delete any media ranges containing a wildcard character '*'
          from the Accept header.  Delete the language-range '*', if
          present, from the Accept-Language header.  Delete the
          wildcard '*', if present, from the Accept-Features header.

   As another example, the overall quality factor for the variant

     {"blah.html" 1 {language en-gb} {features blebber [x y]}}

   is 1 and definite with the Accept headers

     Accept-Language: en-gb, fr
     Accept-Features: blebber, x, !y, *

   and

     Accept-Language: en, fr
     Accept-Features: blebber, x, *

   The overall quality factor is still 1, but speculative, with the
   Accept headers

     Accept-language: en-gb, fr
     Accept-Features: blebber, !y, *

   and

     Accept-Language: fr, *
     Accept-Features: blebber, x, !y, *


11.5 Determining the result

   The best variant, as determined by the network negotiation
   algorithm, is the one variant with the highest overall quality
   value, or, if there are multiple variants which share the highest
   overall quality, the first variant in the list with this value.

11.5.1 Result for proxies and origin servers

   When running on a proxy or origin server, the result of the network
   negotiation algorithm is determined as follows.

   1. If the negotiable resource and the best variant resource are not
      neighbors, then the result is List_UA if the user agent is
      capable of transparent content negotiation, List_OS otherwise.
      This rule exists for security reasons: it prevents some forms of
      spoofing, see Section 15.2.

   2. If the above rule does not apply, then

      a. If the user agent is capable of transparent content
         negotiation, the result is Choice_UA if the best variant has
         a definite overall quality value greater than 0, and List_UA
         otherwise.

      b. If the user agent is not capable of transparent content
         negotiation, the result is Choose_OS if the best variant has
         a (definite or speculative) overall quality value which is
         greater than 0, or at least the value of the "min-q"
         directive if this directive is present in the Alternates
         header.  If the result is not Choose_OS, it is Forward_OS if
         the Alternates header contains the "forward" directive and
         the algorithm is running on a proxy, and List_OS otherwise.

11.5.2 Result for user agents

   When running on a user agent, the result of the network negotiation
   algorithm is Choice_UA if the best variant has an overall quality
   value greater than 0, and List_UA otherwise.


11.6 Construction of short requests

   Under normal HTTP semantics, the interpretation of the request
   header `Accept: */*' is

     `I accept all media types with a quality of 1.0'.

   One of the most important properties of the network negotiation
   algorithm is that this interpretation is different if the header is
   sent by a user agent which supports transparent content
   negotiation. In this case, the interpretation of the header is

     `I accept several media types, and assign quality factors from 0.0
     up to 1.0 to them.  If this information is insufficient to make a
     choice on my behalf, do not make a choice but send the list of
     variants'.

   The complete absence of an Accept header from the request would be
   interpreted in the same way.

   This means that a user agent which supports transparent content
   negotiation can send a minimal request, without any Accept headers
   but with a Negotiate header, by default:

      GET /paper HTTP/1.1
      Host: x.org
      User-Agent: WuxtaWeb/2.4
      Negotiate:

   The sending of this minimal request will never have an adverse
   effect on the quality of the transparent negotiation process: if
   the requested resource happens to be transparently negotiated, the
   user agent will always get a list response, so that it can choose
   the best variant itself.  Only the speed of the negotiation process
   can be affected, because servers will no longer be able to cut
   corners by choosing on behalf of the user agent.

   If it is found that the requests to a particular origin server
   often return a less efficient list response, the user agent can
   dynamically introduce short Accept headers in its future requests
   to that server, for example

      GET /paper HTTP/1.1
      Host: x.org
      User-Agent: WuxtaWeb/2.4
      Negotiate:
      Accept: text/html, application/postscript:q=0.8, */*
      Accept-language: en, fr;q=0.5

   This will increase the chance that the network negotiation
   algorithm will have sufficient information to choose on behalf of
   the user agent, thereby optimizing the negotiation process.  A good
   strategy for dynamic extension would be to extend the request with
   with those media types, languages, charsets, and feature tags
   mentioned in the variant lists of past list responses from the
   server.  The Accept header in the extended request, if present,
   will generally contain "*/*" to indicate that only partial
   information is given in this header.  The Accept-Features header,
   if present, will generally contain a "*" for the same reason.


12 User agent support for transparent negotiation

   This section specifies the requirements a user agent must satisfy
   in order to support transparent negotiation.  If the user agent
   contains an internal cache, this cache should satisfy the
   requirements for proxy caches in Section 14.


12.1 Handling of responses

   If a list response is received when a resource is accessed, the
   user agent must be able to automatically choose, retrieve, and
   display the best variant, or display an error message if it is not
   capable of displaying any of the available variants.  The
   negotiation algorithm which chooses the best variant (or chooses to
   display an error message) need not be the network negotiation
   algorithm.

   If a choice response is received when a resource is accessed, the
   usual action is to automatically display the enclosed variant.  A
   user agent may however choose to apply its (custom) negotiation
   algorithm to the received variant list, and to automatically
   retrieve and display another variant if the algorithm indicates
   that this other variant has a better quality.

   When receiving a choice response, a user agent should check if the
   if the negotiable resource and the chosen variant resource are
   neighbors.  If this is not the case, the user agent should reject
   the choice response as a probable spoofing attempt and display an
   error message, for example by internally replacing the choice
   response with a 502 (bad gateway) response.


12.2 Presentation of a transparently negotiated resource

   If the user agent is displaying, in a main window (i.e. not as an
   embedded or inlined object), a variant as the end result of a
   request on a transparently negotiated resource, the following
   requirements must be met.

    1. The user agent should make available though its user interface
       some indication that the resource being displayed is a
       negotiated resource.

    2. The user agent should allow the user to review a list of all
       variants bound to the negotiable resource, and to manually
       retrieve another variant if desired.  There are two general
       ways of providing such a list.  First, the information in the
       Alternates header of the negotiable resource could be used to
       make an annotated menu of variants.  Second, the entity
       included in a list response of the negotiable resource could be
       displayed.  Note that a list response can always be obtained by
       doing a GET request on the negotiable resource with a Negotiate
       header but without Accept headers.  If only this second option
       is provided, the user agent should also provide the user with a
       means to review the real variant list as used by the
       negotiation algorithm (see Section 15.1).

    3. If the user agent shows the URI of the displayed information to
       the user, it should be the negotiable resource URI, not the
       variant URI.

    4. Similarly, if the user agent stores a reference to the
       displayed information for future use, for example in a hotlist,
       it should store the negotiable resource URI, not the
       variant URI.

   It is encouraged, but not required, that some of the above
   functionality is also made available for inlined or embedded
   objects, and when a variant which was selected manually is being
   displayed.


13 Origin server support for transparent negotiation

   This section covers origin server support from a HTTP viewpoint.
   see Appendix 19.2 for implementation considerations.


13.1 Requirements

   To implement transparent negotiation on a resource, the origin
   server must be able to send a list response when getting a GET
   request on the resource.  It should also be able to send
   appropriate list responses for HEAD requests.  The origin server
   must always send a list response, never a choice response, for a
   request with a Negotiate header but without Accept headers.

   The origin server may also return choice responses, except in the
   special case above.  The negotiation algorithm used need not be the
   network negotiation algorithm.

   Negotiability is a binary property: a resource is either
   transparently negotiated, or it is not.  Origin servers should not
   vary the negotiability of a resource, or the variant list bound to
   that resource, based on the request headers which are received.
   The variant list and the property of being negotiated may however
   change through time.  The Cache-Control header and the max-age
   directive of the Alternates header can be used to control the
   propagation of such time-dependent changes through caches.

   It is the responsibility of the author of the negotiable resource
   to ensure that all resources in the variant list serve the intended
   content, and that the variant resources do not engage in
   transparent content negotiation themselves.


13.2 Negotiation on transactions other than GET and HEAD

   If a resource is transparently negotiable, this only has an impact
   on the GET and HEAD transactions on the resource.  Other
   transactions are not affected.  If it is desired that transparent
   content negotiation is done on, for example, the end result of a
   POST request, then a 303 (See Other) POST response which redirects
   to a negotiable resource could be generated.  See the HTTP/1.1
   specification [1] for details.


14 Proxy support for transparent negotiation

   Transparent content negotiation is designed to work through proxies
   which only implement the HTTP/1.1 specification [1].  Thus, in a
   sense, all HTTP/1.1 proxies support transparent content
   negotiation.

   Plain HTTP/1.1 allows proxies to cache list and choice responses,
   and to efficiently revalidate them by using the If-None-Match
   header.  This specification defines additional optimization
   mechanisms.

   First, a proxy may cache and reuse an Alternates header bound to a
   negotiable resource (Section 10.3).  If it is fresh or first-hand,
   the Alternates header may be reused to negotiate on behalf of the
   user agent or origin server and to construct choice responses
   (Section 10.2.2).  Proxies must not use custom negotiation
   algorithms, they may only use the network negotiation algorithm.

   Second, if a proxy receives a choice response, it may extract and
   cache the normal response embedded therein, as described in
   Section 10.4.


15 Security and privacy considerations

15.1 Accept headers revealing information of a private nature

   Accept headers, in particular Accept-Language headers, may reveal
   information which the user would rather keep private unless it will
   directly improve the quality of service.  For example, a user may
   not want to send language preferences to sites which do not offer
   multi-lingual content.  The transparent content negotiation
   mechanism allows user agents to omit sending of the Accept-Language
   header by default, without this affecting the outcome of the
   negotiation process if transparently negotiated multi-lingual
   content is accessed.

   However, even if Accept headers are never sent, the automatic
   selection and retrieval of a variant by a user agent will reveal a
   preference for this variant to the server.  A malicious service
   author could provide a page with `fake' negotiability on
   (ethnicity-correlated) languages, with all variants actually being
   the same English document, as a means of obtaining
   privacy-sensitive information.  Such a plot would however be
   visible to an alert victim if the list of available variants and
   their properties is reviewed.

   Some additional privacy considerations connected to Accept headers
   are discussed in [1].


15.2 Spoofing of responses from variant resources

   The caching optimization in Section 10.4 gives the implementer of a
   negotiable resource control over the responses cached for all of
   its variant resources which are neighbors.  This is a security
   problem if a neighboring variant resource belongs to another
   author.  To provide security in this case, the HTTP server will
   have to filter the Content-Location headers in the choice responses
   generated by the negotiable resource implementation.


16 Acknowledgments

   Work on HTTP content negotiation has been done since at least 1993.
   The author is unable to trace the origin of many of the ideas
   incorporated in this document.  This document builds on an earlier
   specification of content negotiation as recorded in [2].  Many
   members of the HTTP working group have contributed to the work
   reflected in this document.  The author wishes to thank the
   individuals who have commented on earlier versions of this
   document, including Brian Behlendorf, Daniel DuBois, Larry
   Masinter, and Roy T. Fielding.


17 References

   [1] Fielding et al, Hypertext Transfer Protocol -- HTTP/1.1.
       Internet-Draft draft-ietf-http-v11-spec-06.txt, HTTP Working
       Group, July 4, 1996

   [2] Roy T. Fielding, Henrik Frystyk Nielsen, and Tim Berners-Lee.
       Hypertext Transfer Protocol -- HTTP/1.1.  Internet-Draft
       draft-ietf-http-v11-spec-01.txt, HTTP Working Group, January,
       1996.


18 Author's address

   Koen Holtman
   Technische Universiteit Eindhoven
   Postbus 513
   Kamer HG 6.57
   5600 MB Eindhoven (Holland)

   e-mail: koen@win.tue.nl


19 Appendices

19.1 Adding an Expires header to ensure HTTP/1.0 compatibility

   To ensure compatibility with HTTP/1.0 caching proxies which do not
   recognize the Vary header, an Expires header with a date in the
   past can be be added to the response, for example

        Expires: Thu, 01 Jan 1980 00:00:00 GMT

   If this is done by an origin server, it should usually also include
   a Cache-Control header for the benefit of HTTP/1.1 caches, for
   example

              Cache-Control: max-age=604800

   which overrides the freshness lifetime of zero seconds specified by
   the included Expires header.


19.2 Origin server implementation considerations

19.2.1 Implementation with a CGI script

   [##Has yet to be written.  This section will contain a sample CGI
   shell script.##]

19.2.2 Direct support by the HTTP server

   [##Has yet to be written.  Will discuss the interface which a
   transparent content negotiation server module could offer to
   content authors.  Will provide references to existing
   implementations of content negotiation modules.##]

19.2.3 Negotiable content authoring

   [##Has yet to be written.  Mainly intends to mention that authoring
   tools could automatically produce multiple variants together with
   an appropriate variant list.##]


19.3 Open issues in transparent content negotiation

   At the time of writing of this specification, the following issues
   are still open.

   - The feature tag registration process has yet to be defined.

   - A core set of feature tags (Section 8.2) has not yet been
     defined, though there has been some related work on display
     attributes, see Appendix 19.4.1.

   - Though it is expected that the feature negotiation framework will
     solve many current and future negotiation problems, it is also
     expected that there will remain current and future negotiation
     problems not solved by feature negotiation.  Currently, there is
     little experience in this area.


19.4 Other negotiation specifications

19.4.1 User-Agent Display Attributes Headers

   (Comments based on the internet draft
   draft-mutz-http-attributes-00.txt and on messages from Andy Mutz.)

   User-Agent Display Attributes provide a means for an HTTP client to
   inform a server about its display capabilities.  The draft
   mentioned above defines a number of such attributes, and presents
   them as part of a HTTP/1.0 style negotiation framework (See Section
   4.2).  However, the the author of the above draft has said that the
   draft does not intend to specify a negotiation framework, but
   instead intends to use the framework proposed for negotiating
   the existing header information.  PEP (Section 19.4.2) and
   transparent content negotiation are mentioned as possible
   frameworks.

   In the opinion of the author of this document, the feature
   negotiation framework would be an appropriate mechanism for
   negotiation on display attributes.  It seems possible and desirable
   to encapsulate display attributes in the feature negotiation
   mechanism, and to make them part of the core set of feature tags
   (Section 8.2).

   The work on feature negotiation has its historical origins in the
   desire to negotiate on display agent attributes with a minimum of
   overhead to the request size.  The work started after a discussion
   of color content negotiation on the http-wg mailing list showed
   that many participants found the introduction of a header like
   Accept-Color unacceptable.  Reasons cited were the request size
   overhead, and the potential explosion of special-case Accept-*
   headers, all of which would require special-case implementations,
   implied by the introduction of Accept-Color.


19.4.2 PEP: An Extension Mechanism for HTTP/1.1

   (Comments based on the internet draft draft-khare-http-pep-01.txt.)

   PEP is a system for HTTP clients, servers, and proxies to reliably
   reason about custom extensions to HTTP.  Its purpose places PEP one
   meta-level above transparent content negotiation, which is intended
   as a (standardized) extension of HTTP.

   Transparent content negotiation and HTTP/1.1 were both carefully
   designed to work together without requiring meta-negotiation.
   Therefore, transparent content negotiation does not require or rely
   on the use of PEP.

   Though PEP and transparent content negotiation both offer
   extensible negotiation frameworks, they operate in different areas
   of negotiation.  PEP negotiates on the use of mutually understood
   protocol extensions, while transparent content negotiation is a
   method for efficiently retrieving the best representation of some
   information.  Thus, deployment and use of PEP is orthogonal to
   deployment and use of transparent content negotiation.

   Though some elements of PEP resemble some elements of transparent
   content negotiation, it does not seem advantageous to attempt to
   generalize (parts of) both specifications in order to allow sharing
   of code by implementations.  The two specifications seem to have
   more unrelated parts than similar parts.  For example, the handling
   of incomplete information in Accept headers in transparent content
   negotiation has no counterpart in PEP.  On the other hand, PEP's
   processing of `scope' has no counterpart in transparent content
   negotiation.


19.5 Related issues

19.5.1 Current negotiation practice

   In current practice, most user agents send short Accept headers in
   every request.  These headers usually inadequately describe the
   user agent capabilities and user preferences, except maybe for
   inline image requests.  Servers providing multiple representations
   of the same information usually do so under different URIs, and
   allow users to manually select a representation by clicking a
   particular link.

   Some HTTP servers implement extensive negotiation capabilities
   based on HTTP/1.0 headers.  However, with current user agents,
   these capabilities can seldom be used effectively.

   Some origin servers use the contents of the User-Agent request
   header for negotiation purposes.  These contents sometimes allow
   the server to infer information about capabilities which cannot be
   expressed with the existing Accept headers.

   Some sites use Netscape cookies (persistent client state http
   cookies) to implement a user preferences mechanism.

19.5.2 Bandwidth negotiation

   With a bandwidth negotiation mechanism, the time needed to retrieve
   a particular variant over the network can be taken into account
   during the negotiation process.  Work on mechanisms for bandwidth
   negotiation has been done since at least 1993, but this work has
   not yet yielded a successful standard mechanism for bandwidth
   negotiation.  Cascaded proxy caches introduce additional complexity
   in this area.

   This specification does not attempt to solve the problem of
   bandwidth negotiation.  There is some hope that the feature
   negotiation framework will allow the introduction of an adequate
   solution for bandwidth negotiation.

19.5.3 Content transformation by proxies

   Recently, there has been some attention to content transformation by
   proxies.  An example is the transformation of an image/gif response
   to a shorter image/jpeg response, with potential degraded quality, to
   save bandwidth.  Another example is the transformation of an
   application/postscript response to a text/html response, with
   definite degraded quality, to allow viewing by a user agent which
   cannot handle postscript.

   The impact of such transformations on the quality of content on the
   web, and the impact on the current model for the allocation of trust
   to various parties in a HTTP transaction, has not yet been fully
   explored.

   Content transformation could be a useful optimization for transparent
   content negotiation.  A response with a variant list

     {"map.gif" 1.0 {type image/gif} {features !monochrome}},
     {"map.mono.gif" 0.8 {type image/gif} {features monochrome}}

   could include an additional response header

     Allow-Transform: "map.gif" -> "map.mono.gif" with "dither-2"

   to allow a proxy which has cached "map.gif" to create "map.mono.gif"
   on demand, by applying a particular standardized transformation to
   the "map.gif" data.  Another interesting possibility would be

     Allow-Transform: "map.gif" -> "map.mono.gif"
                    with "http://x.org/java/filters/my_dither"


Expires: February 14, 1997
