rfc2295.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,711 行 · 第 1/5 页

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

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

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

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

     HTTP/1.1 200 OK
     Date: Tue, 11 Jun 1996 20:05:31 GMT
     TCN: choice
     Content-Type: text/html
     Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
     Content-Length: 5327
     Cache-control: max-age=604800
     Content-Location: paper.1
     Alternates: {"paper.1" 0.9 {type text/html} {language en}},



Holtman & Mutz                Experimental                     [Page 13]

RFC 2295            Transparent Content Negotiation           March 1998


                 {"paper.2" 0.7 {type text/html} {language fr}},
                 {"paper.3" 1.0 {type application/postscript}
                     {language en}}
     Etag: "gonkyyyy;1234"
     Vary: negotiate, accept, accept-language
     Expires: Thu, 01 Jan 1980 00:00:00 GMT

     <title>A paper about ....

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

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

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

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

4.5 Downwards compatibility with non-negotiating user agents

   To handle requests from user agents which do not support transparent
   content negotiation, this specification allows the origin server to
   revert to a HTTP/1.0 style negotiation scheme.  The specification of
   heuristics for such schemes is beyond the scope of this document.









Holtman & Mutz                Experimental                     [Page 14]

RFC 2295            Transparent Content Negotiation           March 1998


4.6 Retrieving a variant by hand

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

4.7 Dimensions of negotiation

   Transparent content negotiation defines four dimensions of
   negotiation:

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

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

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

4.8 Feature negotiation

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

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

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





Holtman & Mutz                Experimental                     [Page 15]

RFC 2295            Transparent Content Negotiation           March 1998


4.9 Length of variant lists

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

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

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

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

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

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

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

4.10 Relation with other negotiation schemes

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






Holtman & Mutz                Experimental                     [Page 16]

RFC 2295            Transparent Content Negotiation           March 1998


5  Variant descriptions

5.1 Syntax

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

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

       source-quality = qvalue

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

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

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

   The feature-list syntax is defined in section 6.4.

   Examples are

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

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

      {"paper.1" 0.001}

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

5.2 URI

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



Holtman & Mutz                Experimental                     [Page 17]

RFC 2295            Transparent Content Negotiation           March 1998


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

5.3 Source-quality

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

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

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

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

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

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

   When assigning source-quality values, servers should not account for
   the size of the variant and its impact on transmission and rendering
   delays; the size of the variant should be stated in the length
   attribute and any size-dependent calculations should be done by the
   variant selection algorithm.  Any constant rendering delay for a
   particular media type (for example due to the startup time of a
   helper application) should be accounted for by the user agent, when
   assigning a quality factor to that media type.




Holtman & Mutz                Experimental                     [Page 18]

RFC 2295            Transparent Content Negotiation           March 1998


5.4 Type, charset, language, and length

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

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

   has the counterpart attributes

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

   The language and length attributes carry the same information as
   their Content-* response header counterparts in [1].  The length