rfc2938.txt

RFC 的详细文档！

   might be to leave this as an application protocol issue (but this
   could lead to non-interoperable feature sets between different
   protocols).

   Another conceivable issue is that of up-casing the feature expression
   in preparation for computing a hash value.  This does not apply to
   the content of strings so is not likely to be an issue.  But if
   changes are made that do permit non-US-ASCII characters in feature
   tags or token strings, consideration must be given to properly
   defining how case conversion is to be performed.

6. Security Considerations

   For the most part, security considerations are the same as those that
   apply for capability identification in general [1,2,9].

   A possible added consideration is that use of a specific feature set
   identifier may reveal more information about a system than is
   necessary for a transaction at hand.

7. Acknowledgements

   Ideas here have been improved by early discussions with Martin
   Duerst, Al Gilman and Ted Hardie.  Useful suggestions for improvement
   were provided by Maurizio Codogno.

8. References

   [1]  Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
        2533, March 1999.

   [2]  Mutz, A. and T. Hardie, "Media Feature Tag Registration
        Procedure", RFC 2506, March 1999.

   [3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [4]  Freed, N. and N. Borenstein,  "Multipurpose Internet Mail
        Extensions (MIME) Part 1: Format of Internet message bodies",
        RFC 2045, November 1996.

   [5]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

   [6]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
        1992.





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


   [7]  "Applied Cryptography"
        Bruce Schneier
        John Wiley and Sons, 1996 (second edition)
        ISBN 0-471-12845-7 (cloth)
        ISBN 0-471-11709-9 (paper)

   [8]  Klyne, G., "Protocol-independent Content Negotiation Framework",
        RFC 2703, September 1999.

   [9]  "Numerical Recipes"
        William H Press, Brian P Flannery, Saul A Teukolski and
        William T Vetterling
        Cambridge University Press (1986)
        ISBN 0 521 30811 9
        (The Gamma function approximation is presented in chapter 6 on
        "Special Functions".  There have been several later editions of
        this book published, so the chapter reference may change.)

   [10] Daniel, R. and M. Mealling, "Resolution of Uniform Resource
        Identifiers using the Domain Name System", RFC 2168, June 1997.

   [11] Java source code of feature set matching algorithm, with feature
        set hash computation option.  Linked from
        <http://www.imc.org/ietf-medfree/>



























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


9. Authors' Addresses

   Graham Klyne
   Content Technologies Ltd.
   1220 Parkview,
   Arlington Business Park
   Theale
   Reading, RG7 4SA
   United Kingdom

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Larry Masinter
   AT&T Labs
   75 Willow Road
   Menlo Park, CA 94025

   Phone: [phone]
   EMail: [e-mail]
   http://larry.masinter.net




























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


10. Appendix A: The birthday paradox

       NOTE: this entire section is commentary, and does not affect the
       feature set reference specification in any way.

   The use of a hash value to represent an arbitrary feature set is
   based on a presumption that no two distinct feature sets will yield
   the same hash value.

   There is a small but distinct possibility that two different feature
   sets will indeed yield the same hash value.

   We assume that the 128-bit hash function distributes hash values for
   feature sets, even those with very small differences, randomly and
   evenly through the range of 2^128 (approximately 3*10^38) possible
   values.  This is a fundamental property of a good digest algorithm
   like MD5.  Thus, the chance that any two distinct feature set
   expressions yield the same hash is less than 1 in 10^38.  This is
   negligible when compared with, say, the probability that a receiving
   system will fail having received data conforming to a negotiated
   feature set.

   But when the number of distinct feature sets in circulation
   increases, the probability of repeating a hash value increases
   surprisingly.  This is illustrated by the "birthday paradox":  given
   a random collection of just 23 people, there is a greater than even
   chance that there exists some pair with the same birthday.  This
   topic is discussed further in sections 7.4 and 7.5 of Bruce
   Schneier's "Applied Cryptography" [7].

   The table below shows the "birthday paradox" probabilities that at
   least one pair of feature sets has the same hash value for different
   numbers of feature sets in use.

          Number of feature   Probability of two
          sets in use         sets with the same
                              hash value
          1                   0
          2                   3E-39
          10                  1E-37
          1E3                 1E-33
          1E6                 1E-27
          1E9                 1E-21
          1E12                1E-15
          1E15                1E-9
          1E18                1E-3





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


       The above probability computations are approximate, being
       performed using logarithms of a Gamma function
       approximation by Lanczos [9].  The probability formula is
       'P=1-(m!/((m-n)! m^n))', where 'm' is the total number of
       possible hash values (2^128) and 'n' is the number of
       feature sets in use.

   If original feature set expressions are generated manually, or only
   in response to some manually constrained process, the total number
   of feature sets in circulation is likely to remain very small in
   relation to the total number of possible hash values.

   The outcome of all this is: assuming that the feature sets are
   manually generated, even taking account of the birthday paradox
   effect, the probability of incorrectly identifying a feature set
   using a hash value is still negligibly small when compared with
   other possible failure modes.


































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


11.  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Klyne & Masinter            Standards Track                    [Page 18]