rfc2938.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                            G. Klyne
Request for Comments: 2938                           Content Technologies
Updates: 2533                                                 L. Masinter
Category: Standards Track                                            AT&T
                                                           September 2000


                  Identifying Composite Media Features

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   In RFC 2533, an expression format is presented for describing media
   feature capabilities as a combination of simple media feature tags.

   This document describes an abbreviated format for a composite media
   feature set, based upon a hash of the feature expression describing
   that composite.

Table of Contents

   1.    Introduction ................................................2
   1.1   Organization of this document ...............................2
   1.2   Terminology and document conventions ........................2
   2.    Motivation and goals ........................................3
   3.    Composite feature representation ............................4
   3.1   Feature set hashed reference format .........................5
   3.1.1 Hash value calculation ......................................6
   3.1.2 Base-32 value representation ................................7
   3.2   Resolving feature set identifiers ...........................8
   3.2.1 Query protocol ..............................................8
   3.2.2 Inline feature set details ..................................9
   4.    Examples ...................................................10
   5.    Internationalization Considerations ........................12
   6.    Security Considerations ....................................13
   7.    Acknowledgements ...........................................13
   8.    References .................................................13



Klyne & Masinter            Standards Track                     [Page 1]

RFC 2938          Identifying Composite Media Features    September 2000


   9.    Authors' Addresses .........................................15
   10.   Appendix A: The birthday paradox ...........................16
   11.   Full Copyright Statement ...................................18

1. Introduction

   In "A Syntax for Describing Media Feature Sets" [1], an expression
   format is presented for describing media feature capabilities as a
   combination of simple media feature tags [2].

   This document proposes an abbreviated format for a composite media
   feature set, based upon a hash of the feature expression describing
   that composite.

   This memo extends and builds upon the expression syntax described in
   RFC 2533 [1], and it is assumed that the reader is familiar with the
   interpretation of feature set expressions described there.

1.1 Organization of this document

   Section 2 sets out some of the background and goals for feature set
   references.

   Section 3 presents a syntax for feature set references, and describes
   how they are related to feature set expressions.

1.2 Terminology and document conventions

   This section defines a number of terms and other document
   conventions, which are used with specific meaning in this memo.  The
   terms are listed in alphabetical order.

   dereference
            the act of replacing a feature set reference with its
            corresponding feature set expression.  Also called
            "resolution".

   feature set
            some set of media features described by a media feature
            assertion, as described in "A Syntax for Describing Media
            Feature Sets" [1].  (See that memo for a more formal
            definition of this term.)

   feature set expression
            a string that describes some feature set, formulated
            according to the rules in "A Syntax for Describing Media
            feature sets" [1] (and possibly extended by other
            specifications).



Klyne & Masinter            Standards Track                     [Page 2]

RFC 2938          Identifying Composite Media Features    September 2000


   feature set reference
            a brief construct that references some feature set.  (See
            also: "dereference".)

   feature set tag
            a name that conforms to the syntax of a feature tag [2] that
            is used to denote a feature set rather than a single
            feature.

   resolution
            (See "dereference").

   This specification uses syntax notation and conventions described
   in RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" [3].

       NOTE: Comments like this provide additional nonessential
       information about the rationale behind this document.  Such
       information is not needed for building a conformant
       implementation, but may help those who wish to understand the
       design in greater depth.

2. Motivation and goals

   The range of media feature capabilities of a message handling system
   can be quite extensive, and the corresponding feature set expression
   [1] can reach a significant size.

   A requirement has been identified to allow recurring feature sets to
   be identified by a single reference value, which can be combined with
   other elements in a feature set expression.  It is anticipated that
   mechanisms will be provided that allow the recipient of such a
   feature set reference to discover the corresponding feature set
   expression, but any such mechanism is beyond the scope of this
   specification.

   Thus, the goals for this proposal are:

   o  to provide an abbreviated form for referencing an arbitrary
      feature set expression.

   o  the meaning of (i.e., the corresponding feature set expression) a
      feature set reference should be independent of any particular
      mechanism that may be used to dereference it.

   o  to be able to verify whether a given feature set expression
      corresponds to some feature set reference without having to
      perform an explicit dereferencing operation (i.e., without
      incurring additional network traffic).



Klyne & Masinter            Standards Track                     [Page 3]

RFC 2938          Identifying Composite Media Features    September 2000


   o  for protocol processors that conform to RFC 2533 [1] to be able to
      sensibly handle a feature set reference without explicit knowledge
      of its meaning (i.e., the introduction of feature set references
      should not break existing feature expression processors).  That
      is, the applicable interpretation and processing rules of RFC 2533
      [1] apply equally to expressions containing feature set
      references.

       NOTE:  This proposal does not attempt to address the "override"
       or "default" problem.  (Where a feature set may be referenced and
       selectively modified.)

   Some circumstances in which such an abbreviated form might be used
   include:

   o  A media feature expression that contains a repeated sub-
      expression.  If the sub-expression is quite large, space can be
      saved by writing it out once, then using the abbreviated form to
      reference it.

   o  A capability that is common to a range of devices, such as a given
      class of fax machine where are large number of feature tags are
      involved, but only a small number of common feature sets.  If the
      recipient understands, or can discover, that some abbreviation
      stands for a given feature set then feature expression size can be
      reduced by using the abbreviation.

      If feature set abbreviations are used in this way, it may be that
      they can be interpreted by a simple table lookup rather than full
      feature expression parsing.  (Making this useful in practice will
      depend on crafting the feature subsets appropriately.)

   Examples of such usage are given in section 4 of this memo.

   This memo does not specify how a program that receives a feature set
   abbreviation should discover the corresponding feature set
   expression: see section 3.2.

3. Composite feature representation

   This specification hinges on two central ideas:

   o  the use of auxiliary predicates (introduced in RFC 2533 [1]) to
      form the basis of a feature set identifier, and

   o  the use of a token based on a hash function computed over the
      referenced feature set expression.




Klyne & Masinter            Standards Track                     [Page 4]

RFC 2938          Identifying Composite Media Features    September 2000


   A key reason to use a hash function to generate an identifier is to
   define a global name space without requiring a central naming
   authority.  New feature set tags can be introduced by any party
   following the appropriate rules of formulation, without reference to
   any centralized authority.

   Local resolution services may be needed to map feature set tags to
   their corresponding feature set expressions, but these are not able
   to vary the meaning of any given tag.  Failure of a resolution
   service to return the correct expression is detectable by a calling
   application, which should reject any incorrect value supplied.

       NOTE:  where a feature set reference is used, its meaning is
       defined by substitution of the referenced feature expression into
       the referencing expression.  When all references have been thus
       replaced, the result is interpreted as a normal feature
       expression.

       In particular, if a referenced feature expression contains some
       feature tag that is also constrained by the referencing
       expression, the constraints are interpreted per RFC 2533 [1],
       without regard for their origin.  E.g., (using some notation
       introduced below):
          (& (pix-x=100) (pix-y<=300)
             (h.SBB5REAOMHC09CP2GM4V07PQP0) )
       where (h.SBB5REAOMHC09CP2GM4V07PQP0) resolves to:
          (& (pix-x<=200) (pix-y<=150) )
       yields a result equivalent to:
          (& (pix-x=100) (pix-y<=150) )

3.1 Feature set hashed reference format

   This specification introduces a special form of auxiliary predicate
   name with the following syntax:

     fname       = "h." 1*BASE32DIGIT
     BASE32DIGIT = DIGIT
                 / "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H"
                 / "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P"
                 / "Q" / "R" / "S" / "T" / "U" / "V"

   The sequence of base-32 digits represents the value of a hash
   function calculated over the corresponding feature set expression
   (see following sections).  Note that the above syntax allows upper-
   or lower-case letters for base-32 digits (per RFC 2234 [3]).






Klyne & Masinter            Standards Track                     [Page 5]

RFC 2938          Identifying Composite Media Features    September 2000


   Thus, within a feature set expression, a hashed feature set reference
   would have the following form:

      (h.123456789abcdefghijklmnopq)

3.1.1 Hash value calculation

   The hash value is calculated using the MD5 algorithm [6] over the
   text of the referenced feature set expression subjected to certain
   normalizations.  The feature expression must conform to the syntax
   given for 'filter' in RFC 2533 [1]:

      filter = "(" filtercomp ")" *( ";" parameter )

   The steps for calculating a hash value are:

   1. Whitespace normalization: all spaces, CR, LF, TAB and any other
      layout control characters that may be embedded in the feature
      expression string, other than those contained within quoted
      strings, are removed (or ignored for the purpose of hash value
      computation).

   2. Case normalization:  all lower case letters in the feature
      expression, other than those contained within quoted strings, are
      converted to upper case.  That is, unquoted characters with US-
      ASCII values 97 to 122 (decimal) are changed to corresponding
      characters in the range 65 to 90.

   3. Hash computation: the MD5 algorithm, described in RFC 1321 [6], is
      applied to the normalized feature expression string (represented
      as a sequence of octets containing US-ASCII character codes;  see
      also section 5).

      The result obtained in step 3 is a 128-bit (16 octet) value that
      is converted to a base-32 representation to form the feature set
      reference.

       NOTE:  under some circumstances, removal of ALL whitespace may
       result in an invalid feature expression string.  This should not
       be a problem as this is done only for the purpose of calculating
       a hash value, and significantly different feature expressions are
       expected to differ in ways other than their whitespace.

       NOTE: case normalization is deemed appropriate since feature tag
       and token matching is case insensitive.






Klyne & Masinter            Standards Track                     [Page 6]