rfc2295.txt

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

   attribute, if present, MUST thus reflect the length of the variant
   alone, and not the total size of the variant and any objects inlined
   or embedded by the variant.

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

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

5.5 Features

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

5.6 Description

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



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


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

5.7 Extension-attribute

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

6  Feature negotiation

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

6.1 Feature tags

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

      ftag = token | quoted-string

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

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

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

      tables, fonts, blebber, wolx, screenwidth, colordepth



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


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

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

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

6.1.1 Feature tag values

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

      tag-value  = token | quoted-string

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

6.2 Feature sets

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

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

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

      ( feature tag , set of feature tag values )






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


   If a record with a feature tag is present in the set, this means that
   the user agent implements the corresponding capability, or that the
   user has expressed the corresponding preference.

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

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

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

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

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

6.3 Feature predicates

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

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

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

   Feature predicates are used in features attributes (section 6.4),
   which are used in variant descriptions (section 5).  Variant
   descriptions can be transmitted in Alternates headers (section 8.3).





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


   Examples of feature predicates are

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

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

      ftag       true if the feature is present, false otherwise

      !ftag      true if the feature is absent, false otherwise

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

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

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

   As an example, with the feature set

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

   the following predicates are true:

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

   and the following predicates are false:

      !blex, blebber, colordepth=6, colordepth=foo, !colordepth,
      screenwidth, screenwidth=640, screenwidth!=640, x-version=99, UA-
      media=screen, paper=A0, paper=a4, x-version=[100-199], wuxta






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


6.4 Features attribute

      The features attribute, for which section 5.1 defines the syntax

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

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

       feature-list = 1%feature-list-element

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

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

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

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

   Examples are:

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

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

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

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

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





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


7  Remote variant selection algorithms

   A remote variant selection algorithm is a standardized algorithm by
   which a server can choose a best variant on behalf of a negotiating
   user agent.  The use of a remote algorithm can speed up the
   negotiation process by eliminating a request-response round trip.

   A remote algorithm typically computes whether the Accept- headers in
   the request contain sufficient information to allow a choice, and if
   so, which variant is the best variant.  This specification does not
   define any remote algorithms, but does define a mechanism to
   negotiate on the use of such algorithms.

7.1 Version numbers

   A version numbering scheme is used to distinguish between different
   remote variant selection algorithms.

      rvsa-version = major "." minor

      major = 1*4DIGIT
      minor = 1*4DIGIT