📄 rfc2938.txt
字号:
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 20009. Authors' Addresses Graham Klyne Content Technologies Ltd. 1220 Parkview, Arlington Business Park Theale Reading, RG7 4SA United Kingdom Phone: +44 118 930 1300 Fax: +44 118 930 1301 EMail: GK@ACM.ORG Larry Masinter AT&T Labs 75 Willow Road Menlo Park, CA 94025 Phone: +1-650-463-7059 EMail: LMM@acm.org http://larry.masinter.netKlyne & Masinter Standards Track [Page 15]RFC 2938 Identifying Composite Media Features September 200010. 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-3Klyne & 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 200011. 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]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -