rfc2533.txt

中、英文RFC文档大全打包下载完全版 .

   (! f1 )             is the logical negation of the filter value
                       'f1'.  That is, it is satusfied by any feature
                       collection that does NOT satisfy the predicate
                       represented by 'f1'.

4.2.2 Feature comparison

   A feature comparison is defined by the 'simple' option of the syntax
   production for 'item'. There are three basic forms:

   (ftag=value)        compares the feature named 'ftag' (in some
                       feature collection that is being tested) with
                       the supplied 'value', and matches if they are
                       equal.  This can be used with any type of
                       feaure value (numeric, Boolean, token or
                       string).

   (ftag<=value)       compares the numeric feature named 'ftag' with
                       the supplied 'value', and matches if the
                       feature is less than or equal to 'value'.

   (ftag>=value)       compares the numeric feature named 'ftag' with
                       the supplied 'value', and matches if the
                       feature is greater than or equal to 'value'.

   Less-than and greater-than tests may be performed with feature values
   that are not numeric but, in general, they amount to equality tests
   as there is no ordering relation on non-numeric values defined by
   this specification.  Specific applications may define such ordering
   relations on specific feature tags, but such definitions are beyond
   the scope of (and not required for conformance to) this
   specification.

4.2.3 Feature tags

   Feature tags conform to the syntax given in "Media Feature Tag
   Registration Procedure" [3].  Feature tags used to describe
   capabilities should be registered using the procedures described in
   that memo.  Unregistered feature tags should be allocated in the "URI
   tree", as discussed in the media feature registration procedures memo
   [3].

   If an unrecognized feature tag is encountered in the course of
   feature set predicate processing, it should be still be processed as
   a legitimate feature tag.  The feature set matching rules are
   designed to allow new feature tags to be introduced without affecting
   the validity of existing capability assertions.




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


4.2.4 Feature values

   A feature may have a number, Boolean, token or string value.

4.2.4.1 Boolean values

   A Boolean is simply a token with two predefined values: "TRUE" and
   "FALSE".  (Upper- or lower- case letters may be used in any
   combination.)

4.2.4.2 Numeric values

   A numeric value is either a decimal integer, optionally preceded by a
   "+" or "-" sign, or rational number.

   A rational number is expressed as "n/m", optionally preceded by a "+"
   or "-" sign.  The "n" and "m" are unsigned decimal integers, and the
   value represented by "n/m" is "n" divided by "m".  Thus, the
   following are all valid representations of the number 1.5:

      3/2
      +15/10
      600/400

   Thus, several rational number forms may express the same value.  A
   canonical form of rational number is obtained by finding the highest
   common factor of "n" and "m", and dividing both "n" and "m" by that
   value.

   A simple integer value may be used anywhere in place of a rational
   number.  Thus, we have:

      +5 is equivalent to +5/1 or +50/10, etc.
      -2 is equivalent to -2/1 or -4/2, etc.

   Any sign in a rational number must precede the entire number, so the
   following are not valid rational numbers:

      3/+2, 15/-10      (**NOT VALID**)

4.2.4.3 Token values

   A token value is any sequence of letters, digits and '-' characters
   that conforms to the syntax for 'token' given above.  It is a name
   that stands for some (unspecified) value.






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


4.2.4.4 String values

   A string value is any sequence of characters enclosed in double
   quotes that conform to the syntax for 'string' given above.

   The semantics of string defined by this memo are the same as those
   for a token value.  But a string allows a far greater variety of
   internal formats, and specific applications may choose to interpret
   the content in ways that go beyond those given here.  Where such
   interpretation is possible, the allowed string formats and the
   corresponding interpretations should be indicated in the media
   feature registration (per RFC 2506 [3]).

4.2.5 Notational conveniences

   The 'set' option of the syntax production for 'item' is simply a
   shorthand notation for some common situations that can be expressed
   using 'simple' constructs.  Occurrences of 'set' items can eliminated
   by applying the following identities:

      T = [ E1, E2, ... En ]  -->  (| (T=[E1]) (T=[E2]) ... (T=[En]) )
      (T=[R1..R2])            -->  (& (T>=R1) (T<=R2) )
      (T=[E])                 -->  (T=E)

   Examples:

   The expression:
      ( paper-size=[A4,B4] )
   can be used to express a capability to print documents on either A4
   or B4 sized paper.

   The expression:
      ( width=[4..17/2] )
   might be used to express a capability to print documents that are
   anywhere between 4 and 8.5 inches wide.

   The set construct is designed so that enumerated values and ranges
   can be combined in a single expression, e.g.:
      ( width=[3,4,6..17/2] )

4.3 Feature set definition example

   The following is an example of a feature predicate that describes a
   number of image size and resolution combinations, presuming the
   registration and use of 'Pix-x', 'Pix-y', 'Res-x' and 'Res-y' feature
   tags:

      (| (& (Pix-x=1024)



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


            (Pix-y=768)
            (| (& (Res-x=150) (Res-y=150) )
               (& (Res-x=150) (Res-y=300) )
               (& (Res-x=300) (Res-y=300) )
               (& (Res-x=300) (Res-y=600) )
               (& (Res-x=600) (Res-y=600) ) ) )
         (& (Pix-x=800)
            (Pix-y=600)
            (| (& (Res-x=150) (Res-y=150) )
               (& (Res-x=150) (Res-y=300) )
               (& (Res-x=300) (Res-y=300) )
               (& (Res-x=300) (Res-y=600) )
               (& (Res-x=600) (Res-y=600) ) ) ) ;q=0.9
         (& (Pix-x=640)
            (Pix-y=480)
            (| (& (Res-x=150) (Res-y=150) )
               (& (Res-x=150) (Res-y=300) )
               (& (Res-x=300) (Res-y=300) )
               (& (Res-x=300) (Res-y=600) )
               (& (Res-x=600) (Res-y=600) ) ) ) ;q=0.8 )

5. Matching feature sets

   This section presents a procedure for combining feature sets to
   determine the common feature collections to which they refer, if
   there are any.  Making a selection from the possible feature
   collections (based on q-values or otherwise) is not covered here.

   Matching a feature set to some given feature collection is
   essentially very straightforward:  the feature set predicate is
   simply evaluated for the given feature collection, and the result
   (TRUE or FALSE) indicates whether the feature collection matches the
   capabilities, and the associated quality value can be used for
   selecting among alternative feature collections.

   Matching a feature set to some other feature set is less
   straightforward.  Here, the problem is to determine whether or not
   there is at least one feature collection that matches both feature
   sets (e.g. is there an overlap between the feature capabilities of a
   given file format and the feature capabilities of a given recipient?)

   This feature set matching is accomplished by logical manipulation of
   the predicate expressions as described in the following sub-sections.

   For this procedure to work reliably, the predicates must be reduced
   to a canonical form.  The canonical form used here is "disjunctive
   normal form".  A syntax for disjunctive normal form is:




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


      filter     =  orlist
      orlist     =  "(" "|" andlist ")" / term
      andlist    =  "(" "&" termlist ")" / term
      termlist   =  1*term
      term       =  "(" "!" simple ")" / simple

   where "simple" is as described previously in section 4.1.  Thus, the
   canonicalized form has at most three levels:  an outermost "(|...)"
   disjunction of "(&...)" conjunctions of possibly negated feature
   value tests.

      NOTE:  The usual canonical form for predicate expressions is
      "clausal form".  Procedures for converting general predicate
      expressions are given in [5] (section 10.2), [11] (section 2.13)
      and [12] (section 5.3.2).

      "Clausal form" for a predicate is similar to "conjunctive normal
      form" for a proposition, being a conjunction (logical AND) of
      disjunctions (logical ORs).  The related form used here, better
      suited to feature set matching, is "disjunctive normal form",
      which is a logical disjunction (OR) of conjunctions (ANDs).  In
      this form, the aim of feature set matching is to show that at
      least one of the disjunctions can be satisfied by some feature
      collection.

      Is this consideration of canonical forms really required?  After
      all, the feature predicates are just Boolean expressions, aren't
      they?  Well, no: a feature predicate is a Boolean expression
      containing primitive feature value tests (comparisons),
      represented by 'item' in the feature predicate syntax.  If these
      tests could all be assumed to be independently TRUE or FALSE, then
      each could be regarded as an atomic proposition, and the whole
      predicate could be dealt with according to the (relatively simple)
      rules of Propositional Calculus.

      But, in general, the same feature tag may appear in more than one
      predicate 'item', so the tests cannot be regarded as independent.
      Indeed, interdependence is needed in any meaningful application of
      feature set matching, and it is important to capture these
      dependencies (e.g. does the set of resolutions that a sender can
      supply overlap the set of resolutions that a recipient can
      handle?).  Thus, we have to deal with elements of the Predicate
      Calculus, with some additional rules for algebraic manipulation.

      A description of both the Propositional and Predicate calculi can
      be found in [12].





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


      We aim to show that these additional rules are more unfamiliar
      than complicated.  The construction and use of feature predicates
      actually avoids some of the complexity of dealing with fully-
      generalized Predicate Calculus.

5.1 Feature set matching strategy

   The overall strategy for matching feature sets, expanded below, is:

   1. Formulate the feature set match hypothesis.

   2. Replace "set" expressions with equivalent comparisons.

   3. Move logical negations "inwards", so that they are all applied
      directly to feature comparisons.

   4. Eliminate logical negations, and express all feature comparisons
      in terms of just four comparison operators

   5. Reduce the hypothesis to canonical disjunctive normal form (a
      disjunction of conjunctions).

   6. For each of the conjunctions, attempt to show that it can be
      satisfied by some feature collection.

      6.1  Separate the feature value tests into independent feature
         groups, such that each group contains tests involving just one
         feature tag.  Thus, no predicate in a feature group contains a
         feature tag that also appears in some other group.

      6.2  For each feature group, merge the various constraints to a
         minimum form.  This process either yields a reduced expression
         for the allowable range of feature values, or an expression
         containing the value FALSE, which is an indication that no
         combination of feature values can satisfy the constraints (in
         which case the corresponding conjunction can never be
         satisfied).

   7. If the remaining disjunction contains at least one satisfiable
      conjunction, then the constraints are shown to be satisfiable.

   The final expression obtained by this procedure, if it is non-empty,
   can be used as a statement of the resulting feature set for possible
   further matching operations.  That is, it can be used as a starting
   point for combining with additional feature set constraint predicate
   to determine a feature set that is constrained by the capabilities of
   several entities in a message transfer path.




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