RFC2938 日本語訳
2938 Identifying Composite Media Features. G. Klyne, L. Masinter. September 2000. (Format: TXT=34451 bytes) (Updates RFC2533) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Klyne
Request for Comments: 2938 Content Technologies
Updates: 2533 L. Masinter
Category: Standards Track AT&T
September 2000
Klyneがコメントのために要求するワーキンググループG.をネットワークでつないでください: 2938の満足している技術アップデート: 2533年のL.Masinterカテゴリ: 標準化過程AT&T2000年9月
Identifying Composite Media Features
合成メディア機能を特定します。
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(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.
RFC2533では、式形式は、特徴がタグ付けをする簡単なメディアの組み合わせとしてメディア特徴能力を記述するために提示されます。
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
1. 序論…2 1.1 このドキュメントの組織…2 1.2 用語とドキュメントコンベンション…2 2. 動機と目標…3 3. 特徴表現を合成してください…4 3.1特徴セットは正書法を論じ尽くしました…5 3.1 .1 値の計算を論じ尽くしてください…6 3.1 .2 基地-32は表現を評価します…7 3.2 特徴を決議すると、識別子は設定されました…8 3.2 .1 プロトコルについて質問してください…8 3.2 .2のインライン機能は詳細を設定しました…9 4. 例…10 5. 国際化問題…12 6. セキュリティ問題…13 7. 承認…13 8. 参照…13
Klyne & Masinter Standards Track [Page 1] RFC 2938 Identifying Composite Media Features September 2000
特徴2000年9月に合成メディアを特定するKlyne&Masinter標準化過程[1ページ]RFC2938
9. Authors' Addresses .........................................15 10. Appendix A: The birthday paradox ...........................16 11. Full Copyright Statement ...................................18
9. 作者のアドレス…15 10. 付録A: 誕生日のパラドックス…16 11. 完全な著作権宣言文…18
1. Introduction
1. 序論
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].
「特徴が設定するメディアを説明するための構文」[1]では、式形式は、簡単なメディア機能の組み合わせが[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.
このメモは、RFC2533[1]で説明された式構文を、広げていて、当てにします、そして、読者がそこで説明される特徴セット式の解釈に詳しいと思われます。
1.1 Organization of this document
1.1 このドキュメントの組織
Section 2 sets out some of the background and goals for feature set references.
セクション2は特徴セット参照のバックグラウンドと目標のいくつかを出します。
Section 3 presents a syntax for feature set references, and describes how they are related to feature set expressions.
セクション3は、特徴セット参照のための構文を提示して、特徴セット式にどう関連するかを説明します。
1.2 Terminology and document conventions
1.2 用語とドキュメントコンベンション
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.)
特徴はメディア特徴主張で説明された何らかのセットのメディア機能を設定しました、「特徴が設定するメディアを説明するための構文」[1]で説明されるように。 (今期の、より正式な定義に関してそのメモを見てください。)
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).
設定していて、定式化されて「特徴が設定するDescribingメディアのためのSyntax」[1]の規則に従って(ことによると他の仕様で広げられます)の何らかの特徴について説明するセット式aストリングを特徴としてください。
Klyne & Masinter Standards Track [Page 2] RFC 2938 Identifying Composite Media Features September 2000
特徴2000年9月に合成メディアを特定するKlyne&Masinter標準化過程[2ページ]RFC2938
feature set reference
a brief construct that references some feature set. (See
also: "dereference".)
何らかの特徴セットに参照をつける設定参照a簡潔な構造物を特集してください。 (参照: "反参照"。)
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.
特徴セットは単独形体よりむしろ特徴セットを指示するのに使用される特徴タグ[2]の構文に従う名前にタグ付けをします。
resolution
(See "dereference").
解決("反参照"を見ます)。
This specification uses syntax notation and conventions described in RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" [3].
この仕様がRFC2234で説明された構文記法とコンベンションを使用する、「構文仕様のための増大しているBNF:」 "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.
以下に注意してください。 このようなコメントは原理の追加不要不急な情報をこのドキュメントの後ろに供給します。 そのような情報は、conformant実装を築き上げるのに必要ではありませんが、より大きい深さでデザインを理解したがっている人を助けるかもしれません。
2. Motivation and goals
2. 動機と目標
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.
メッセージハンドリングシステムのメディア特徴能力の範囲はかなり高である場合があります、そして、対応する特徴セット式[1]は重要なサイズに達することができます。
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 任意の特徴に参照をつけるための簡略化されたフォームを提供するには、式を設定してください。
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 (すなわち、対応する特徴セット式)特徴セット参照の意味は反参照に使用されるどんな特定のメカニズムの独立者もそれであるならそうするでしょうに。
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).
o 与えられた特徴セット式が何らかの特徴に対応するかどうか確かめることができるには、明白な「反-参照をつけ」操作(すなわち、追加ネットワークトラフィックを被ることのない)を実行する必要はなくて、参照を設定してください。
Klyne & Masinter Standards Track [Page 3] RFC 2938 Identifying Composite Media Features September 2000
特徴2000年9月に合成メディアを特定するKlyne&Masinter標準化過程[3ページ]RFC2938
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.
o 意味(すなわち、特徴セット参照の導入は既存の特徴式プロセッサを壊すべきでない)の形式知なしで特徴セット参照を分別よく扱うことができるようにRFC2533[1]に一致しているプロトコルプロセッサのために。 すなわち、RFC2533[1]の適切な解釈と処理規則は等しく特徴セット参照を含む式に適用されます。
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 メディアは繰り返されたサブ式を含む式を特徴とします。 サブ式がかなり大きいなら、スペースはそれを書き上げることによって一度節約されて、次に、簡略化されたフォームを参照に使用するのが、それであったなら大きいことができます。
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.
o さまざまなデバイスに共通の能力、ファックスの与えられたクラスがどこを機械加工するかときの多くの特徴タグがかかわるというそのようなものによることですが、少ない数の共通点だけがセットします。 受取人が、分かるか、または何らかの略語が与えられた特徴を表すのがセットしたと発見できるなら、特徴式サイズは、略語を使用することによって、減少できます。
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.
そのような用法に関する例はこのメモのセクション4で出されます。
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.2を見てください。
3. Composite feature representation
3. 合成特徴表現
This specification hinges on two central ideas:
この仕様は2つの主要な考えに依ります:
o the use of auxiliary predicates (introduced in RFC 2533 [1]) to
form the basis of a feature set identifier, and
o そして補助の述部の使用、(特徴セット識別子の基礎を形成するためにRFC2533[1])で導入する。
o the use of a token based on a hash function computed over the
referenced feature set expression.
o ハッシュ関数に基づくトークンの使用は参照をつけられた特徴セット式に関して計算されました。
Klyne & Masinter Standards Track [Page 4] RFC 2938 Identifying Composite Media Features September 2000
特徴2000年9月に合成メディアを特定するKlyne&Masinter標準化過程[4ページ]RFC2938
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) )
参照をつけられた特徴式がまた、参照箇所式によって抑制されるある特徴タグを含んでいるなら、特に、規制はRFC2533[1]単位で解釈されます、それらの発生源への尊敬なしで。 例えば(以下で導入された何らかの記法を使用します): ((写真-x=100)(写真y<=300)(h.SBB5REAOMHC09CP2GM4V07PQP0)) (h.SBB5REAOMHC09CP2GM4V07PQP0)が、決議するところで: ((写真x<=200)(写真y<=150)) 以下に同等な結果をもたらします。 ((写真-x=100)(写真y<=150))
3.1 Feature set hashed reference format
3.1特徴セットは正書法を論じ尽くしました。
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"
fnameは「h.」と等しいです。 等しい..ケタ..C
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]).
ベース-32ケタの系列は対応する特徴セット式に関して計算されたハッシュ関数の値を表します(以下の章を見てください)。 上の構文がベース-32ケタのための上側の、または、小文字の手紙を許容することに注意してください。(RFC2234[3])単位で。
Klyne & Masinter Standards Track [Page 5] RFC 2938 Identifying Composite Media Features September 2000
特徴2000年9月に合成メディアを特定するKlyne&Masinter標準化過程[5ページ]RFC2938
Thus, within a feature set expression, a hashed feature set reference would have the following form:
したがって、特徴セット式の中では、以下は論じ尽くされた特徴セット参照によって形成されるでしょう:
(h.123456789abcdefghijklmnopq)
(h.123456789abcdefghijklmnopq)
3.1.1 Hash value calculation
3.1.1 ハッシュ値計算
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]:
ハッシュ値は、ある正常化にかけられた参照をつけられた特徴セット式のテキストの上でMD5アルゴリズム[6]を使用することで計算されます。 特徴式はRFC2533[1]で'フィルタ'のために与えられた構文に従わなければなりません:
filter = "(" filtercomp ")" *( ";" parameter )
「("filtercomp")」というフィルタ=*(「」、;、パラメタ)
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).
1. 空白正常化: すべての空間(CRとLFとTABと引用文字列の中に含まれたもの以外の特徴式ストリングに埋め込まれるかもしれないいかなる他のレイアウト制御文字も)を取り除きます(または、ハッシュ値計算の目的のために、無視されます)。
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.
2. 正常化をケースに入れてください: 引用文字列の中に含まれたもの以外の特徴式におけるすべての小文字が大文字に変換されます。 すなわち、米国ASCII値97〜122(10進)がある引用を終わっているキャラクタは65〜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).
3. 計算を論じ尽くしてください: RFC1321[6]で説明されたMD5アルゴリズムは正常にされた特徴式ストリング(米国-ASCII文字コード; また、セクション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.
ステップ3で得られた結果は特徴セット参照を形成するためにベース-32表現に変換される128ビット(16八重奏)の値です。
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] RFC 2938 Identifying Composite Media Features September 2000
特徴2000年9月に合成メディアを特定するKlyne&Masinter標準化過程[6ページ]RFC2938
3.1.2 Base-32 value representation
3.1.2 基地-32値の表現
RFC 1321 [6] describes how to calculate an MD5 hash value that is a sequence of 16 octets. This is then required to be coded as a base- 32 value, which is a sequence of base-32 digit characters.
RFC1321[6]は16の八重奏の系列であるMD5ハッシュ値について計算する方法を説明します。 そして、これが、ベース32価値としてコード化されるのに必要です。(価値はベース-32のケタキャラクタの系列です)。
Each successive character in a base-32 value represents 5 successive bits of the underlying octet sequence. Thus, each group of 8 characters represents a sequence of 5 octets (40 bits):
ベース-32値におけるそれぞれの連続したキャラクタは基本的な八重奏系列の連続した5ビットを表します。 したがって、8つのキャラクタの各グループは5つの八重奏(40ビット)の系列を表します:
1 2 3
01234567 89012345 67890123 45678901 23456789
+--------+--------+--------+--------+--------+
|< 1 >< 2| >< 3 ><|.4 >< 5.|>< 6 ><.|7 >< 8 >|
+--------+--------+--------+--------+--------+
<===> 8th character
<====> 7th character
<===> 6th character
<====> 5th character
<====> 4th character
<===> 3rd character
<====> 2nd character
<===> 1st character
1 2 3 01234567 89012345 67890123 45678901 23456789 +--------+--------+--------+--------+--------+ |1>の<<2| ><3><|.4><5.| ><6><| 7><8>| +--------+--------+--------+--------+--------+ <。===>8番目のキャラクタ<。====>7番目のキャラクタ<。===>6番目のキャラクタ<。====>5番目のキャラクタ<。====>4番目のキャラクタ<。===>3番目のキャラクタ<。====>2番目のキャラクタ<。===>最初のキャラクタ
The value (i.e. sequence of bits) represented by each base-32 digit character is indicated by the following table:
それぞれのベース-32ケタキャラクタによって表された値(すなわち、ビットの系列)は以下のテーブルによって示されます:
"0" 0 "A" 10 "K" 20 "U" 30
"1" 1 "B" 11 "L" 21 "V" 31
"2" 2 "C" 12 "M" 22
"3" 3 "D" 13 "N" 23
"4" 4 "E" 14 "O" 24
"5" 5 "F" 15 "P" 25
"6" 6 "G" 16 "Q" 26
"7" 7 "H" 17 "R" 27
"8" 8 "I" 18 "S" 28
"9" 9 "J" 19 "T" 29
0インチ..1インチ..2インチ..C..3インチ..4インチ..5インチ..6インチ..7インチ..8インチ..9インチ
When encoding a base-32 value, each full group of 5 octets is represented by a sequence of 8 characters indicated above. If a group of less than 5 octets remain after this, they are encoded using as many additional characters as may be needed: 1, 2, 3 or 4 octets are encoded by 2, 4, 5 or 7 characters respectively. Any spare bits represented by the base-32 digit characters are selected to be zero.
ベース-32値をコード化するとき、5つの八重奏のそれぞれの完全なグループは上で示された8つのキャラクタの系列によって代表されます。 5つ未満の八重奏のグループがこの後残っているなら、それらは必要とされるかもしれないのと同じくらい多くの添字を使用することでコード化されます: 1 2 3か4つの八重奏が2、4、5または7つのキャラクタによってそれぞれコード化されます。 ベース-32のケタキャラクタによって表されたどんな予備ビットもゼロであることが選択されます。
Klyne & Masinter Standards Track [Page 7] RFC 2938 Identifying Composite Media Features September 2000
特徴2000年9月に合成メディアを特定するKlyne&Masinter標準化過程[7ページ]RFC2938
When decoding a base-32 value, the reverse mapping is applied: each full group of 8 characters codes a sequence of 5 octets. A final group of 2, 4, 5 or 7 characters codes a sequence of 1, 2, 3 or 4 octets respectively. Any spare bits represented by the final group of characters are discarded.
ベース-32値を解読するとき、逆のマッピングは適用されています: 8つのキャラクタのそれぞれの完全なグループは5つの八重奏の系列をコード化します。 2、4人の最終的なグループ、5か7つのキャラクタがそれぞれ1、2、3または4つの八重奏の系列をコード化します。 キャラクタの最終的なグループによって表されたどんな予備ビットも捨てられます。
Thus, for a 128-bit (16 octet) MD5 hash value, the first 15 octets are coded as 24 base 32 digit characters, and the final octet is coded by two characters.
したがって、24が32のケタキャラクタを基礎づけて、128ビット(16八重奏)のMD5ハッシュ値において、最初の15の八重奏がコード化されます、そして、最終的な八重奏は2つのキャラクタによってコード化されます。
NOTE: Base64 representation (per MIME [4]) would be more compact
(21 rather than 26 characters for the MD5 128-bit hash value),
but an auxiliary predicate name is defined (by [1]) to have the
same syntax as a feature tag, and the feature tag matching rules
(per [2]) state that feature tag matching is case insensitive.
以下に注意してください。 特徴タグ、および特徴と同じ構文を持つ[1])で合っている規則にタグ付けをしてください。Base64表現、([4])がMIMEに従ってよりコンパクトでしょうが(MD5の128ビットのハッシュ値のための26のキャラクタよりむしろ21)、補助の述語名が定義される、((特徴タグマッチングが大文字と小文字を区別しないと[2])単位で述べてください。
Base36 representation was considered (i.e., using all letters
"A"-"Z") but was not used because this would require extended
precision multiplication and division operations to encode and
decode the hash values.
これはハッシュ値をコード化して、解読するために拡大精度乗除操作を必要とするでしょう、Base36表現は、考えられましたが(すなわち、「A」--「Z」というすべての手紙を使用します)、したがって、使用されませんでした。
3.2 Resolving feature set identifiers
3.2 特徴セット識別子を決議すること。
This memo does not mandate any particular mechanism for dereferencing a feature set identifier. It is expected that specific dereferencing mechanisms will be specified for any application or protocol that uses them.
このメモは、特徴セット識別子に「反-参照をつけ」るためにどんな特定のメカニズムも強制しません。 特定の「反-参照をつけ」メカニズムがそれらを使用するどんなアプリケーションやプロトコルにも指定されると予想されます。
The following sections describe some ways that feature set dereferencing information may be incorporated into a feature set expression. These are based on auxiliary predicate definitions within a "where" clause [1].
以下のセクションは情報に「反-参照をつけ」るように設定された特徴が法人組織であるかもしれないいくつかの方法を特徴セット式に述べます。 これらは「どこ」節[1]の中で補助の述部定義に基づいているか。
When a hashed feature set reference is used, conformance to the hashing rules takes precedence over any other determination of the feature expression. Any expression, however obtained, may not be substituted for the hash-based reference unless it yields the correct hash value.
論じ尽くされた特徴セット参照が使用されているとき、論じ尽くす規則への順応は特徴式のいかなる他の決断の上でも優先します。 正しいハッシュ値をもたらさない場合、どんなしかしながら、得られた式もハッシュベースの参照に代入されないかもしれません。
3.2.1 Query protocol
3.2.1 質問プロトコル
A protocol providing request/response type queries (e.g., HTTP, LDAP, etc.) might be set up to provide a resolution service.
要求/応答タイプ質問(例えば、HTTP、LDAPなど)を提供するプロトコルは、解決サービスを提供するためにセットアップされるかもしれません。
Thus, a query to a server associated with the capabilities could be performed on the feature set identifier. The response returned would be a CONNEG expression; e.g.,
したがって、特徴セット識別子に能力に関連しているサーバへの質問を実行できました。 返された応答はCONNEG式でしょう。 例えば
Klyne & Masinter Standards Track [Page 8] RFC 2938 Identifying Composite Media Features September 2000
特徴2000年9月に合成メディアを特定するKlyne&Masinter標準化過程[8ページ]RFC2938
(h.SBB5REAOMHC09CP2GM4V07PQP0)
where
(h.SBB5REAOMHC09CP2GM4V07PQP0) :- (& (pix-x<=200) (pix-y<=150) )
end
(h.SBB5REAOMHC09CP2GM4V07PQP0) (h.SBB5REAOMHC09CP2GM4V07PQP0):-((写真x<=200)(写真y<=150))が終わるところ
or just:
正当です:
(& (pix-x<=200) (pix-y<=150) )
((写真x<=200)(写真y<=150))
This result would be combined with the original expression to obtain a result not including the hash based predicate.
この結果は、ハッシュを含んでいないと述部が基づいたという結果を得るためにオリジナルの式に結合されるでしょう。
This process might be further enhanced by using URN resolution mechanisms (e.g., DNS NAPTR [10]) to discover the resolution protocol and server.
このプロセスは、URN解決メカニズムを使用することによって、さらに高められるかもしれません。(例えば、解決プロトコルとサーバを発見するDNS NAPTR[10])。
3.2.2 Inline feature set details
3.2.2 インライン特徴セットの詳細
In this case, a reference is resolved by including its definition inline in an expression.
この場合、参照は、式に定義インラインを含んでいることによって、決議されています。
The feature set expression associated with a reference value may be specified directly in a "where" clause, using the auxiliary predicate definition syntax [1]; e.g.,
基準値に関連している特徴セット式は直接「どこ」節で指定されるかもしれないか、補助の述部定義構文[1]を使用して。 例えば
(& (dpi=100) (h.SBB5REAOMHC09CP2GM4V07PQP0) )
where
(h.SBB5REAOMHC09CP2GM4V07PQP0) :- (& (pix-x<=200) (pix-y<=150) )
end
((dpi=100)(h.SBB5REAOMHC09CP2GM4V07PQP0)) (h.SBB5REAOMHC09CP2GM4V07PQP0):-((写真x<=200)(写真y<=150))が終わるところ
This form might be used on request (where the request mechanism is defined by the invoking application protocol), or when the originator believes the recipient may not understand the reference.
このフォームは要求に応じて(要求メカニズムが呼び出しアプリケーション・プロトコルによって定義されるところ)か創始者が、受取人が参照を理解しないかもしれないと信じているときに時使用されるかもしれません。
It is an error if the inline feature expression does not yield the hash value contained in auxiliary predicate name.
インライン特徴式が補助の述語名に含まれたハッシュ値をもたらさないなら、それは誤りです。
NOTE: viewed in isolation, this format does not have any obvious
value, in that the (h.xxx) form of auxiliary predicate could be
replaced by any arbitrary name.
以下に注意してください。 分離で見られます、この形式には、少しの明白な値もありません、補助の述部の(h.xxx)フォームをどんな任意の名前にも取り替えることができたので。
It is anticipated that this form might be used as a follow-up
response in a sequence along the lines of:
A> Capabilities are:
(& (dpi=100) (h.SBB5REAOMHC09CP2GM4V07PQP0) )
B> Do not understand:
(h.SBB5REAOMHC09CP2GM4V07PQP0)
このフォームが次々に追跡している応答として以下の系列に沿って使用されるかもしれないと予期されます。 >Capabilitiesは以下の通りです。 ((dpi=100)(h.SBB5REAOMHC09CP2GM4V07PQP0)) B>は分かりません: (h.SBB5REAOMHC09CP2GM4V07PQP0)
Klyne & Masinter Standards Track [Page 9] RFC 2938 Identifying Composite Media Features September 2000
特徴2000年9月に合成メディアを特定するKlyne&Masinter標準化過程[9ページ]RFC2938
A> Capabilities are:
(& (dpi=100) (h.SBB5REAOMHC09CP2GM4V07PQP0) )
where
(h.SBB5REAOMHC09CP2GM4V07PQP0) :- (& (pix-x<=200)
(pix-y<=150) )
end
>Capabilitiesは以下の通りです。 ((dpi=100)(h.SBB5REAOMHC09CP2GM4V07PQP0)) (h.SBB5REAOMHC09CP2GM4V07PQP0):-((写真x<=200)(写真y<=150))が終わるところ
4. Examples
4. 例
The following are some examples of feature set expressions containing feature set references:
↓これは特徴セット参照を含む特徴セット式に関するいくつかの例です:
(& (dpi=100) (h.SBB5REAOMHC09CP2GM4V07PQP0) )
((dpi=100)(h.SBB5REAOMHC09CP2GM4V07PQP0))
(& (dpi=100) (h.SBB5REAOMHC09CP2GM4V07PQP0) )
where
(h.SBB5REAOMHC09CP2GM4V07PQP0) :-
(& (pix-x<=200) (pix-y<=150) )
end
((dpi=100)(h.SBB5REAOMHC09CP2GM4V07PQP0)) (h.SBB5REAOMHC09CP2GM4V07PQP0):-((写真x<=200)(写真y<=150))が終わるところ
(h.QGEOPMCF02P09QC016CEPU22FO)
where
(h.QGEOPMCF02P09QC016CEPU22FO) :-
(| (& (ua-media=continuous) (dpi=200) (dpi-xyratio=200/100)
(color=Binary) (paper-size=B4) (image-coding=MH) )
(& (ua-media=continuous) (dpi=200) (dpi-xyratio=200/100)
(color=Binary) (paper-size=B4) (image-coding=MR) )
(& (ua-media=stationery) (dpi=300) (dpi-xyratio=1)
(color=Binary) (paper-size=A4) (image-coding=JBIG) )
(& (ua-media=transparency) (dpi=300) (dpi-xyratio=1)
(h.QGEOPMCF02P09QC016CEPU22FO) where (h.QGEOPMCF02P09QC016CEPU22FO) :- (| (& (ua-media=continuous) (dpi=200) (dpi-xyratio=200/100) (color=Binary) (paper-size=B4) (image-coding=MH) ) (& (ua-media=continuous) (dpi=200) (dpi-xyratio=200/100) (color=Binary) (paper-size=B4) (image-coding=MR) ) (& (ua-media=stationery) (dpi=300) (dpi-xyratio=1) (color=Binary) (paper-size=A4) (image-coding=JBIG) ) (& (ua-media=transparency) (dpi=300) (dpi-xyratio=1)
(color=Binary) (paper-size=A4) (image-coding=JBIG) ) )
end
(=を着色して、2進にします) (紙サイズ=A4)(画像符号化=JBIG) )、終わり
The following examples are based on Internet fax work, and show how a feature-hash might be used to express the commonly-used features. A form of Internet fax system that is expected to be quite common is a so-called "simple mode" system, whose capabilities are described by the following feature expression:
以下の例は、一般的に使用された特徴を言い表すためにインターネットファックス仕事に基づいていて、特徴ハッシュがどう使用されるかもしれないかを示しています。 全く一般的であると予想されるインターネットファックスシステムのフォームは能力が以下の特徴式によって説明されるいわゆる「簡単なモード」システムです:
(& (image-file-structure=TIFF-minimal)
(MRC-mode=0)
(color=Binary)
(image-coding=MH) (MRC-mode=0)
(| (& (dpi=204) (dpi-xyratio=[204/98,204/196]) )
(& (dpi=200) (dpi-xyratio=[200/100,1]) ) )
(size-x<=2150/254)
(paper-size=A4)
((イメージファイル構造=いさかい最小量)(MRC-モード=0)(=を着色して、2進にします)(画像符号化はMHと等しいです)(MRC-モード=0)、(|、((dpi=204)(dpi-xyratio=[204/98,204/196]) )((dpi=200)(dpi-xyratio=[200/100、1])))(サイズx<=2150/254)(紙サイズ=A4)
Klyne & Masinter Standards Track [Page 10] RFC 2938 Identifying Composite Media Features September 2000
特徴2000年9月に合成メディアを特定するKlyne&Masinter標準化過程[10ページ]RFC2938
(ua-media=stationery) )
(ua-メディア=文房具)
This might be expressed by the hash-based feature set identifier:
これはハッシュベースの特徴セット識別子によって言い表されるかもしれません:
(h.MSB955PVIRT1QOHET9AJT5JM3O)
(h.MSB955PVIRT1QOHET9AJT5JM3O)
The following example describes capabilities of a full-color Internet fax system. Note a number of feature values are applicable in common with '(color=grey)' and '(color=full)':
以下の例はフルカラーインターネットファックスシステムの能力について説明します。 多くの特徴値が'(色=灰色)'と'(色=満)'と共用して適切であることに注意してください:
(& (image-file-structure=TIFF)
(MRC-mode=0)
(| (& (color=Binary)
(image-coding=[MH,MR,MMR])
(| (& (dpi=204) (dpi-xyratio=[204/98,204/196]) )
(& (dpi=200) (dpi-xyratio=[200/100,1]) )
(& (dpi=300) (dpi-xyratio=1) ) ) )
(& (color=grey)
(image-coding=JPEG)
(image-coding-constraint=JPEG-T4E)
(color-levels<=256)
(color-space=CIELAB)
(color-illuminant=D50)
(CIELAB-L-min>=0)
(CIELAB-L-max<=100)
(dpi=[100,200,300]) (dpi-xyratio=1) )
(& (color=full)
(image-coding=JPEG)
(image-coding-constraint=JPEG-T4E)
(color-subsampling=["1:1:1","4:1:1"])
(color-levels<=16777216)
(color-space=CIELAB)
(color-illuminant=D50)
(CIELAB-L-min>=0)
(CIELAB-L-max<=100)
(CIELAB-a-min>=-85)
(CIELAB-a-max<=85)
(CIELAB-b-min>=-75)
(CIELAB-b-max<=125)
(dpi=[100,200,300]) (dpi-xyratio=1) ) )
(size-x<=2150/254)
(paper-size=[letter,A4,B4]) )
(ua-media=stationery) )
(ua-メディア=文房具)
Klyne & Masinter Standards Track [Page 11] RFC 2938 Identifying Composite Media Features September 2000
特徴2000年9月に合成メディアを特定するKlyne&Masinter標準化過程[11ページ]RFC2938
Separating out the common capabilities yields:
一般的な能力を分離するのはもたらされます:
(& (image-file-structure=TIFF)
(MRC-mode=0)
(| (& (color=Binary)
(image-coding=[MH,MR,MMR])
(| (& (dpi=204) (dpi-xyratio=[204/98,204/196]) )
(& (dpi=200) (dpi-xyratio=[200/100,1]) )
(& (dpi=300) (dpi-xyratio=1) ) ) )
(& (color=grey)
(color-levels<=256)
(h.QVSEM8V2LMJ8VOR7V682J7079O) )
(& (color=full)
(color-subsampling=["1:1:1","4:1:1"])
(color-levels<=16777216)
(CIELAB-a-min>=-85)
(CIELAB-a-max<=85)
(CIELAB-b-min>=-75)
(CIELAB-b-max<=125)
(h.QVSEM8V2LMJ8VOR7V682J7079O) ) )
(size-x<=2150/254)
(paper-size=[letter,A4,B4]) )
(ua-media=stationery) )
where
(h.QVSEM8V2LMJ8VOR7V682J7079O) :-
(& (image-coding=JPEG)
(image-coding-constraint=JPEG-T4E)
(color-space=CIELAB)
(color-illuminant=D50)
(CIELAB-L-min>=0)
(CIELAB-L-max<=100)
(dpi=[100,200,300]) (dpi-xyratio=1) )
end
((イメージファイル構造はいさかいと等しいです)(MRC-モード=0)、(|、((=を着色して、2進にします)(MH、MR、画像符号化=MMR)、(|、((dpi=204(dpi-xyratio=204/98,204/196))((dpi=200)(dpi-xyratio=200/100、1))((dpi=300)(dpi-xyratio=1))))、((色=灰色)、(レベルを着色している< 着色..いっぱい..色..1インチ..1インチ..色..平らにする..分..最大..分..最大..サイズ..等しい..紙サイズ..手紙; (ua-メディアは文房具と等しいです)) どこ(h.QVSEM8V2LMJ8VOR7V682J7079O) :- ((カラー発光体=D50)(CIELAB-L-分>=0)(CIELAB-L-最大<=100)の(画像符号化はJPEGと等しいです)(イメージをコード化する規制はJPEG-T4Eと等しいです)(色スペース=CIELAB)は終わります(dpiは[100,200,300])(dpi-xyratio=1)と等しいです)。
5. Internationalization Considerations
5. 国際化問題
Feature set expressions and URI strings are currently defined to consist of only characters from the US-ASCII repertoire [1,5]; under these circumstances this specification is not impacted by internationalization considerations (other than any already applicable to URIs [5]).
特徴セット表現とURIストリングは現在、米国-ASCIIレパートリー[1、5]からキャラクタだけから成るように定義されます。 こういう事情ですからこの仕様は国際化問題によって影響を与えられません。(既にURI[5])に適切ないずれを除いても。
But, if future revisions of the feature set syntax permit non-US- ASCII characters (e.g. within quoted strings), then some canonical representation must be defined for the purposes of calculating hash values. One choice might be to use a UTF-8 equivalent representation as the basis for calculating the feature set hash. Another choice
しかし、特徴の今後の改正が構文を設定するなら可能にしてください、非、-米国のASCII文字(例えば、引用文字列の中の)です、そして、ハッシュ値について計算する目的のために何らかの正準な表現を定義しなければなりません。 1つの選択は特徴について計算する基礎が細切れ肉料理を設定したのでUTF-8の同等な表現を使用することであるかもしれません。 別の選択
Klyne & Masinter Standards Track [Page 12] RFC 2938 Identifying Composite Media Features September 2000
特徴2000年9月に合成メディアを特定するKlyne&Masinter標準化過程[12ページ]RFC2938
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.
想像できる別の問題は細切れ肉料理を計算することに備えた特徴表現が評価する上がっているケーシングのものです。 これは、申し込みません。ストリングの内容は問題である傾向がありません。 しかし、特徴タグか象徴ストリングで非米国のASCII文字を可能にする変更を行うなら、適切に実行されるケース変換がことである方法を定義することに対して考慮を払わなければなりません。
6. Security Considerations
6. セキュリティ問題
For the most part, security considerations are the same as those that apply for capability identification in general [1,2,9].
セキュリティ問題は一般に、能力識別[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
7. 承認
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.
ここの考えはマーチンDuerst、アル・ギルマン、およびテッド・ハーディーとの早めの議論で改良されました。 役に立つ改善提案はマウリジオ・コドーニョによって提供されました。
8. References
8. 参照
[1] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
2533, March 1999.
[1]Klyne、G.、「特徴が設定するメディアを説明するための構文」、RFC2533、1999年3月。
[2] Mutz, A. and T. Hardie, "Media Feature Tag Registration
Procedure", RFC 2506, March 1999.
[2]MutzとA.とT.ハーディー、「メディアはタグ登録手順を特徴とする」RFC2506、1999年3月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[3] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part 1: Format of Internet message bodies",
RFC 2045, November 1996.
解放された[4]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)第1部:」 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[5]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、1998年8月。
[6] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[6] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
Klyne & Masinter Standards Track [Page 13] RFC 2938 Identifying Composite Media Features September 2000
特徴2000年9月に合成メディアを特定するKlyne&Masinter標準化過程[13ページ]RFC2938
[7] "Applied Cryptography"
Bruce Schneier
John Wiley and Sons, 1996 (second edition)
ISBN 0-471-12845-7 (cloth)
ISBN 0-471-11709-9 (paper)
[7] 「適用された暗号」のブルース・シュナイアー・ジョン・ワイリーとソンス、1996(第2版)ISBN0-471-12845-7(布)ISBN0-471-11709-9(紙)
[8] Klyne, G., "Protocol-independent Content Negotiation Framework",
RFC 2703, September 1999.
[8]Klyne、G.、「プロトコルから独立している満足している交渉枠組み」、RFC2703、1999年9月。
[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.)
[9] 「数字のレシピ」のウィリアムHプレス、ブライアン・Pフラナリー、サウルA Teukolski、およびウィリアムT Vetterlingケンブリッジ大学出版局(1986)ISBN0 521 30811 9Gamma機能近似は「特別な機能」に第6章に提示されます。(発行されるこの本の数個の後の版があって、したがって、章参照は変化するかもしれません。)
[10] Daniel, R. and M. Mealling, "Resolution of Uniform Resource
Identifiers using the Domain Name System", RFC 2168, June 1997.
[10] ダニエルとR.とM.食事、「ドメインネームシステムを使用するUniform Resource Identifierの決議」、RFC2168、1997年6月。
[11] Java source code of feature set matching algorithm, with feature
set hash computation option. Linked from
<http://www.imc.org/ietf-medfree/>
[11] 特徴のJavaソースコードは特徴セット細切れ肉料理計算オプションで合っているアルゴリズムを設定しました。 <http://www.imc.org/ietf-medfree/>から、リンクされます。
Klyne & Masinter Standards Track [Page 14] RFC 2938 Identifying Composite Media Features September 2000
特徴2000年9月に合成メディアを特定するKlyne&Masinter標準化過程[14ページ]RFC2938
9. Authors' Addresses
9. 作者のアドレス
Graham Klyne Content Technologies Ltd. 1220 Parkview, Arlington Business Park Theale Reading, RG7 4SA United Kingdom
全麦のKlyne満足している技術株式会社1220Parkview、アーリントンビジネスはTheale読書、RG7 4SAイギリスを駐車します。
Phone: +44 118 930 1300 Fax: +44 118 930 1301 EMail: GK@ACM.ORG
以下に電話をしてください。 +44 118 930、1300Fax: +44 1301年の118 930メール: GK@ACM.ORG
Larry Masinter AT&T Labs 75 Willow Road Menlo Park, CA 94025
メンローパーク、ラリーMasinter AT&T研究室75柳のRoadカリフォルニア 94025
Phone: +1-650-463-7059 EMail: LMM@acm.org http://larry.masinter.net
以下に電話をしてください。 +1-650-463-7059 メールしてください: LMM@acm.org http://larry.masinter.net
Klyne & Masinter Standards Track [Page 15] RFC 2938 Identifying Composite Media Features September 2000
特徴2000年9月に合成メディアを特定するKlyne&Masinter標準化過程[15ページ]RFC2938
10. Appendix A: The birthday paradox
10. 付録A: 誕生日のパラドックス
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.
任意の特徴セットを表すハッシュ値の使用は目立った特徴が設定しない2が全く同じハッシュ値をもたらすという推定に基づいています。
There is a small but distinct possibility that two different feature sets will indeed yield the same hash value.
本当に、2つの異なった特徴セットが同じハッシュ値をもたらす小さい、しかし、異なった可能性があります。
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.
私たちは、128ビットのハッシュ関数が特徴セット、非常に小さい違いがあるそれらのためにさえ無作為に均等に2^128(およそ3*10^38)の可能な値の範囲を通ってハッシュ値を分配すると思います。 これはMD5のような良いダイジェストアルゴリズムの基本財産です。 したがって、どんな2つの目立った特徴決まり文句も同じ細切れ肉料理をもたらすという機会は10^38のうちの1未満です。 たとえば、受電方式が交渉された特徴セットに従う受信データを持ちながら失敗するという確率と比べると、これは取るにたらないです。
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].
しかし、流通における、目立った特徴セットの数が増加すると、ハッシュ値を繰り返すという確率は驚いたことに増加します。 これは「誕生日のパラドックス」によって例証されます: ちょうど23人の人の無作為の収集を考えて、何かが存在しているという機会さえより偉大な組が同じ誕生日をもってあります。 ブルース・シュナイアーの「適用された暗号」[7]のセクション7.4と7.5で、より詳しくこの話題について議論します。
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.
以下のテーブルは異なった数の特徴セッツ・イン・ユースのために、少なくとも1組の特徴セットに同じハッシュ値があるという「誕生日のパラドックス」確率を示しています。
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
同じ細切れ肉料理がある2つのセッツ・イン・ユースセットの特徴Probabilityの数は1 0 2 3ユーロの-39 10 1ユーロの-37 1を3 1の1ユーロの6 1Eの9 1ユーロの1-21E12ユーロの1-27 1ユーロの-15 1つEの1ユーロの15-9 1E18EのE-33の1-3E評価します。
Klyne & Masinter Standards Track [Page 16] RFC 2938 Identifying Composite Media Features September 2000
特徴2000年9月に合成メディアを特定するKlyne&Masinter標準化過程[16ページ]RFC2938
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.
ランチョシュ[9]でGamma機能近似の対数を使用することで実行されて、上の確率計算は大体です。 そして、'確率公式が'P=1である、-、(m!/(m-n)!m^n))、'、どこ、'可能なハッシュ値(2^128)が総数があるか、'特徴セッツ・イン・ユースの数はそうです。
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
特徴2000年9月に合成メディアを特定するKlyne&Masinter標準化過程[17ページ]RFC2938
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Klyne & Masinter Standards Track [Page 18]
Klyne&Masinter標準化過程[18ページ]
一覧
スポンサーリンク
