rfc2533.txt

RFC 的详细文档！

   This section develops some example scenarios, introducing the
   notation that is defined formally in section 4.




Klyne                       Standards Track                     [Page 6]

RFC 2533       A Syntax for Describing Media Feature Sets     March 1999


3.4.1 Data resource options

   The following expression describes a data resource that can be
   displayed either:
   (a)  as a 750x500 pixel image using 15 colours, or
   (b)  at 150dpi on an A4 page.

      (| (& (pix-x=750) (pix-y=500) (color=15) )
         (& (dpi>=150) (papersize=iso-A4) ) )

3.4.2 Recipient capabilities

   The following expression describes a receiving system that has:
   (a)  a screen capable of displaying 640*480 pixels and 16 million
        colours (24 bits per pixel), 800*600 pixels and 64 thousand
        colours (16 bits per pixel) or 1024*768 pixels and 256 colours
        (8 bits per pixel), or
   (b)  a printer capable of rendering 300dpi on A4 paper.

         (| (& (| (& (pix-x<=640)  (pix-y<=480) (color<=16777216) )
                  (& (pix-x<=800)  (pix-y<=600) (color<=65535) )
                  (& (pix-x<=1024) (pix-y<=768) (color<=256) ) )
               (ua-media=screen) )
            (& (dpi=300)
               (ua-media=stationery) (papersize=iso-A4) ) )

   Note that this expression says nothing about the colour or grey-scale
   capabilities of the printer.  In the scheme presented here, it is
   presumed to be unconstrained in this respect (or, more realistically,
   any such constraints are handled out-of-band by anyone sending to
   this recipient).

3.4.3 Combined options

   The following example describes the range of document representations
   available when the resource described in the first example above is
   sent to the recipient described in the second example.  This is the
   result of combining their capability feature sets:

         (| (& (pix-x=750) (pix-y=500) (color=15) )
            (& (dpi=300) (ua-media=stationery) (papersize=iso-A4) ) )

   The feature set described by this expression is the intersection of
   the sets described by the previous two capability expressions.







Klyne                       Standards Track                     [Page 7]

RFC 2533       A Syntax for Describing Media Feature Sets     March 1999


3.5 Feature set predicates

   There are many ways of representing a predicate.  The ideas in this
   memo were inspired by the programming language Prolog [5], and its
   use of predicates to describe sets of objects.

   For the purpose of media feature descriptions in networked
   application protocols, the format used for LDAP search filters [7,8]
   has been adopted, because it is a good match for the requirements of
   capability identification, and has a very simple structure that is
   easy to parse and process.

3.5.1 Comparison with directory search filters

   Observe that a feature collection is similar to a directory entry, in
   that it consists of a collection of named values.  Further, the
   semantics of the mechanism for selecting feature collections from a
   feature set is in many respects similar to selection of directory
   entries from a directory.

   A feature set predicate used to describe media handling capabilities
   is implicitly applied to some feature collection.  Within the
   predicate, members of the feature collection are identified by their
   feature tags, and are compared with known feature values.  (Compare
   with the way an LDAP search filter is applied to a directory entry,
   whose members are identified by attribute type names, and compared
   with known attribute values.)

   For example, in:

      (& (dpi>=150) (papersize=iso-A4) )

   the tokens 'dpi' and 'papersize' are feature tags, and '150' and '
   iso-A4' are feature values.  (In a corresponding LDAP search filter,
   they would be directory entry attribute types and attribute values.)

   Differences between directory selection (per [7]) and feature set
   selection are:

      o  Directory selection provides substring-, approximate- and
         extensible- matching for attribute values.  Such matching is
         not provided for feature set selection.

      o  Directory selection may be based on the presence of an
         attribute without regard to its value.  Within the semantic
         framework described by this document, Boolean-valued feature
         tests can be used to provide a similar effect.




Klyne                       Standards Track                     [Page 8]

RFC 2533       A Syntax for Describing Media Feature Sets     March 1999


      o  Directory selection provides for matching rules that test for
         the presence or absence of a named attribute type.

      o  Directory selection provides for matching rules which are
         dependent upon the declared data type of an attribute value.

      o  Feature selection provides for the association of a quality
         value with a feature predicate as a way of ranking the selected
         value collections.

   Within the semantic framework described by this document, Boolean-
   valued feature tests can be used where presence tests would be used
   in a directory search filter.

   The idea of extensible matching and matching rules dependent upon
   data types are facets of a problem not addressed by this memo, but
   which do not necessarily affect the feature selection syntax.  An
   aspect that might bear on the syntax would be specification of an
   explicit matching rule as part of a selection expression.

3.6 Describing preferences

   A convenient way to describe preferences is by numeric "quality
   values".

   It has been suggested that numeric quality values are potentially
   misleading if used as more than just a way of ranking options.  For
   the purposes of this memo, ranking of options is sufficient.

   Numeric quality values in the range 0 to 1, with up to 3 fractional
   digits, are used to rank feature sets according to preference.
   Higher values are preferred over lower values, and equal values are
   presumed to be equally preferred.  Beyond this, the actual number
   used has no significance defined here.  Arithmetic operations on
   quality values are likely to produce unpredictable results unless
   appropriate semantics have been defined for the context where such
   operations are used.

   In the absence of any explicitly applied quality value, a value of
   "1" is assumed.

   Using the notation defined later, a quality value may be attached to
   any feature set predicate sub-expression:

      (| (& (pix-x=750) (pix-y=500) (color=15) );q=0.8
         (& (dpi>=150) (papersize=iso-A4) )     ;q=0.7 )





Klyne                       Standards Track                     [Page 9]

RFC 2533       A Syntax for Describing Media Feature Sets     March 1999


   Section 3.7 below explains that quality values attached to
   sub-expressions are not always useful.

      NOTE:  the syntax for quality values used here taken from
      that defined for HTTP 'Accept:' headers in RFC 2068 [9],
      section 3.9.  However, the use of quality values defined
      here does not go as far as that defined in RFC 2068.

3.7 Combining preferences

   The general problem of describing and combining preferences among
   feature sets is very much more complex than simply describing
   allowable feature sets.  For example, given two feature sets:

      (& (a1);q=0.8 (b1);q=0.7 )
      (& (a2);q=0.5 (b2);q=0.9 )

   where:
      feature a1 is preferred over a2
      feature b2 is preferred over b1

   Which of these feature sets is preferred?  In the absence of
   additional information or assumptions, there is no generally
   satisfactory answer to this.

   The proposed resolution of this issue is simply to say that no rules
   are provided for combining preference information.  Applied to the
   above example, any preference information about (a1) in relation to
   (a2), or (b1) in relation to (b2) is not presumed to convey
   information about preference of (& (a1) (b1) ) in relation to (& (a2)
   (b2) ).

   In practical terms, this restricts the application of preference
   information to top-level predicate clauses.  A top-level clause
   completely defines an allowable feature set;  clauses combined by
   logical-AND operators cannot be top-level clauses (see canonical
   format for feature set predicates, described later).

      NOTE: This memo does not apply specific meaning to quality values
      or rules for combining them.  Application of such meanings and
      rules is not prohibited, but is seen as an area for continuing
      research and experimentation.

      An example of a design that uses extended quality value semantics
      and combining operations is "Transparent Content Negotiation in
      HTTP" [4].  Other work that also extends quality values is the
      content negotiation algorithm in the Apache HTTP server [14].




Klyne                       Standards Track                    [Page 10]

RFC 2533       A Syntax for Describing Media Feature Sets     March 1999


4. Feature set representation

   The foregoing sections have described a framework for defining
   feature sets with predicates applied to feature collections.  This
   section presents a concrete representation for feature set
   predicates.

4.1 Textual representation of predicates

   The text representation of a feature set is based on RFC 2254 "The
   String Representation of LDAP Search Filters" [8], excluding those
   elements not relevant to feature set selection (discussed above), and
   adding elements specific to feature set selection (e.g. options to
   associate quality values with predicates).

   The format of a feature predicate is defined by the production for
   "filter" in the following, using the syntax notation and core rules
   of RFC 2234 [10]:

      filter     =  "(" filtercomp ")" *( ";" parameter )
      parameter  =  "q" "=" qvalue
                 /  ext-param "=" ext-value
      qvalue     =  ( "0" [ "." 0*3DIGIT ] )
                 /  ( "1" [ "." 0*3("0") ] )
      ext-param  =  ALPHA *( ALPHA / DIGIT / "-" )
      ext-value  =  <parameter value, according to the named parameter>
      filtercomp =  and / or / not / item
      and        =  "&" filterlist
      or         =  "|" filterlist
      not        =  "!" filter
      filterlist =  1*filter
      item       =  simple / set / ext-pred
      set        =  attr "=" "[" setentry *( "," setentry ) "]"
      setentry   =  value "/" range
      range      =  value ".." value
      simple     =  attr filtertype value
      filtertype =  equal / greater / less
      equal      =  "="
      greater    =  ">="
      less       =  "<="
      attr       =  ftag
      value      =  fvalue
      ftag       =  <Feature tag, as defined in RFC 2506 [3]>
      fvalue     =  Boolean / number / token / string
      Boolean    =  "TRUE" / "FALSE"
      number     =  integer / rational
      integer    =  [ "+" / "-" ] 1*DIGIT
      rational   =  [ "+" / "-" ] 1*DIGIT "/" 1*DIGIT



Klyne                       Standards Track                    [Page 11]

RFC 2533       A Syntax for Describing Media Feature Sets     March 1999


      token      =  ALPHA *( ALPHA / DIGIT / "-" )
      string     =  DQUOTE *(%x20-21 / %x23-7E) DQUOTE
                    ; quoted string of SP and VCHAR without DQUOTE
      ext-pred   =  <Extension constraint predicate, not defined here>

   (Subject to constraints imposed by the protocol that carries a
   feature predicate, whitespace characters may appear between any pair
   of syntax elements or literals that appear on the right hand side of
   these productions.)

   As described, the syntax permits parameters (including quality
   values) to be attached to any "filter" value in the predicate (not
   just top-level values).  Only top-level quality values are
   recognized.  If no explicit quality value is given, a value of '1.0'
   is applied.

      NOTE:  The flexible approach to quality values and other parameter
      values in this syntax has been adopted for two reasons:  (a) to
      make it easy to combine separately constructed feature predicates,
      and (b) to provide an extensible tagging mechanism for possible
      future use (for example, to incorporate a conceivable requirement
      to explicitly specify a matching rule).

4.2 Interpretation of feature predicate syntax

   A feature set predicate is described by the syntax production for '
   filter'.

4.2.1 Filter syntax

   A 'filter' is defined as either a simple feature comparison ('item',
   see below) or a composite filter ('and', 'or', 'not'), decorated with
   optional parameter values (including "q=qvalue").

   A composite filter is a logical combination of one or more 'filter'
   values:

   (& f1 f2 ... fn )   is the logical-AND of the filter values 'f1',
                       'f2' up to 'fn'.  That is, it is satisfied by
                       any feature collection that satisfies all of