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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
In RFC 2533, an expression format is presented for describing media feature capabilities as a combination of simple media feature tags.
RFC 2533において、表現形式は、単純なメディア特徴タグの組み合わせとしてメディア機能能力を説明するために提示されます。
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
9. Authors' Addresses .........................................15
10. Appendix A: The birthday paradox ...........................16
11. Full Copyright Statement ...................................18
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.
このメモは延び、RFC [1] 2533に記載表現構文に基づいて構築し、読者がそこに記載の機能セット表現の解釈に精通しているものとします。
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節では、機能セットの参照の構文を提示し、それらが集合式を機能に関連している方法について説明します。
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.)
「メディア機能セットを記述するためのA構文」で説明したような特徴は、[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).
特徴[1]（およびおそらく他の仕様によって拡張）「メディア機能セットを記述するための構文」のルールに従って処方いくつかの機能セットを記述する文字列式を設定しました。
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.
機能は、単一の機能ではなく機能セットを示すために使用されている特徴タグ[2]の構文に準拠名をタグを設定します。
resolution (See "dereference").
解像度（「間接参照」を参照してください）。
This specification uses syntax notation and conventions described in RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" [3].
この仕様は、構文記法及びRFC 2234に記載の表記法を使用して、「構文仕様のための増大している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.
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は、明示的な参照解除操作を行うことなく、所定の機能セットの発現は、いくつかの機能セットの基準に対応するか否かを確認することができるように（即ち、追加のネットワークトラフィックを招くことなく）。
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.
（すなわち、機能セット参照の導入は、既存の機能発現プロセッサを壊してはならない）RFC 2533に準拠するプロトコルプロセッサ用O [1]賢明その意味の明示的な知識がなくても機能セットの参照を処理できるようにします。すなわち、[1]機能セットへの参照を含む式に等しく適用される、RFC 2533の適用解釈及び処理ルールです。
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.
このような特徴タグである多数が関与しているFAX機の特定のクラスのような装置、が、共通の機能セットの少数の範囲に共通する能力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節を参照してください：このメモは、機能セットの略語を受け取るプログラムは、対応する機能セット表現を発見する方法を指定しません。
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
機能セット識別子の基礎を形成する（RFC 2533に導入され[1]）補助述語の使用、O、及び
o the use of a token based on a hash function computed over the referenced feature set expression.
O参照フィーチャにわたって計算されたハッシュ関数に基づいてトークンの使用は、発現を設定します。
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) )
参照フィーチャの表現も参照発現によって制約されるいくつかの特徴タグを含む場合、特に、制約は、その起源に関係なく、[1] RFC 2533ごとに解釈されます。例えば、（以下に紹介いくつかの表記を使用して）：（＆（PIX-X = 100）（PIX-Y <= 300）（h.SBB5REAOMHC09CP2GM4V07PQP0））ここで、（h.SBB5REAOMHC09CP2GM4V07PQP0）解決した：（＆（PIX-X <= 200）（PIX-Y <= 150））と同等の結果が得られる：（＆（PIX-X = 100）（PIX-Y <= 150））
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"。 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]).
ベース32桁のシーケンスは、対応する特徴セット式（次の項を参照）を介して計算されたハッシュ関数の値を表します。上記の構文は、（RFC 2234あたりの[3]）ベース32桁のために上位または小文字を可能にすることに留意されたいです。
Thus, within a feature set expression, a hashed feature set reference would have the following form:
したがって、式機能セット内で、ハッシュ化された機能セット基準は、次の形式を有するであろう。
(h.123456789abcdefghijklmnopq)
（h.123456789 abcdefghijklmnop）
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]:
ハッシュ値は、特定の正規化に供参照機能セット表現のテキストの上に[6] MD5アルゴリズムを使用して計算されます。機能表現は、RFC 2533の「フィルタ」に指定された構文に準拠する必要があります[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.ケースの正規化：機能発現におけるすべて小文字、引用符で囲まれた文字列内に含まれるもの以外は、大文字に変換されます。つまり、US-ASCIIと引用符で囲まれていない文字は122（10進数）に97 90の範囲65内の対応する文字に変更された値です。
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.ハッシュ演算：MD5アルゴリズム、RFC 1321に記載され[6]は、正規化された特徴の表現文字列に適用される（US-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.
注：特徴タグとトークンのマッチングは大文字と小文字を区別しないであるので、ケース正規化が適切であると考えられます。
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.
RFC 1321は、[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
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
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つの文字の配列によって表されます。 1、2、3または4つのオクテットは、それぞれ、2、4、5又は7文字によってコードされる：5つの未満オクテットのグループは、この後に残っている場合、それらが必要とされ得る限り多くの追加の文字を使用して符号化されます。ベース32桁の文字で表される任意の予備ビットがゼロであるように選択されます。
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.
したがって、128ビット（16オクテット）MD5ハッシュ値のために、最初の15個のオクテットは24塩基として32桁の文字を符号化され、最終的なオクテットは、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.
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」）を考えられていたが、これはハッシュ値を符号化し、復号化するために拡張精度の乗算と除算演算を必要とするので、使用されませんでした。
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.
ハッシュ機能セットの基準を使用した場合、ハッシュルールへの適合は、機能発現の任意の他の決意に優先します。それが正しいハッシュ値を生成しない限りしかし、得られた任意の式は、ハッシュベースの参照のために置換されていてもよいです。
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表現になります返さ。例えば。、
(h.SBB5REAOMHC09CP2GM4V07PQP0) where (h.SBB5REAOMHC09CP2GM4V07PQP0) :- (& (pix-x<=200) (pix-y<=150) ) end
（h.SBB5REAOMHC09CP2GM4V07PQP0）（h.SBB5REAOMHC09CP2GM4V07PQP0）： - （＆（PIX-X <= 200）（PIX-Y <= 150））終了
or just:
あるいは単に：
(& (pix-x<=200) (pix-y<=150) )
（＆（PIX-X <= 200）（PIX-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.
このプロセスは、さらに解決プロトコルおよびサーバを発見するために（例えば、DNS NAPTR [10]）URN解決メカニズムを使用することによって強化されるかもしれません。
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）： - （＆（PIX-X <= 200）（PIX-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.
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)
このフォームはのラインに沿った配列でフォローアップ応答として使用されるかもしれないことが予想される：A>機能である：（＆（DPI = 100）（h.SBB5REAOMHC09CP2GM4V07PQP0））B>を理解していない：（H。 SBB5REAOMHC09CP2GM4V07PQP0）
A> Capabilities are: (& (dpi=100) (h.SBB5REAOMHC09CP2GM4V07PQP0) ) where (h.SBB5REAOMHC09CP2GM4V07PQP0) :- (& (pix-x<=200) (pix-y<=150) ) end
A>機能は、（＆（DPI = 100）（h.SBB5REAOMHC09CP2GM4V07PQP0））（h.SBB5REAOMHC09CP2GM4V07PQP0）： - （＆（PIX-X <= 200）（PIX-Y <= 150））終了
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）： - （＆（PIX-X <= 200）（PIX-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）（h.QGEOPMCF02P09QC016CEPU22FO）： - （|（＆（UA-メディア）=連続（DPI = 200）（DPI-xyratio = 200/100）（色=バイナリ）（用紙サイズ= B4） （画像符号化= MH））（＆（UA-メディア=連続）（DPI = 200）（DPI-xyratio = 200/100）（色=バイナリ）（用紙サイズ= B4）（画像符号化= MR） （）＆（UA-メディア=文具）（DPI = 300）（DPI-xyratio = 1）（色=バイナリ）（用紙サイズ= A4）（画像符号化= JBIG））（＆（UAメディア=透明）（DPI = 300）（DPI-xyratio = 1）
(color=Binary) (paper-size=A4) (image-coding=JBIG) ) ) end
（色=バイナリ）（用紙サイズ= 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) (ua-media=stationery) )
（＆（イメージファイル構造= TIFF-最小）（MRC-MODE = 0）（色=バイナリ）（画像符号化= MH）（MRC-MODE = 0）（|（＆（DPI = 204）（DPI -xyratio = [204/98204/196]））（＆（DPI = 200）（DPI-xyratio = [200 / 100,1]）））（サイズX <= 254分の2150）（用紙サイズ= A4 ）（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) )
（＆（イメージファイル構造= TIFF）（MRC-MODE = 0）（|（＆（色=バイナリ）（画像符号化= [MH、MR、MMR]）（|（＆（DPI = 204）（ DPI-xyratio = [204/98204/196]））（＆（DPI = 200）（DPI-xyratio = [200 / 100,1]））（＆（DPI = 300）（DPI-xyratio = 1））） （）＆（色=グレー）（画像符号化= JPEG）（画像符号化制約= JPEG-T4E）（色レベル<= 256）（色空間= CIELAB）（色光源= D50）（CIELAB -L分> = 0）（CIELAB-L-MAX <= 100）（DPI = [100,200,300]）（DPI-xyratio = 1））（＆（色=フル）（画像符号化= JPEG）（イメージ - コーディング制約= JPEG-T4E）（カラーサブサンプリング= [ "1：1：1"、 "4：1：1"]）（色レベル<= 16777216）（色空間= CIELAB）（カラー光源= D50）（CIELAB-L分> = 0）（CIELAB-L-MAX <= 100）（CIELAB-分> = - 85）（CIELAB--MAX <= 85）（CIELAB-B-分> = - 75）（CIELAB-B-MAX <= 125）（DPI = [100,200,300]）（DPI-xyratio = 1）））（サイズX <= 254分の2150）（用紙サイズ= [レター、A4 、B4]））（UA-メディア=文房具））
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
（＆（イメージファイル構造= TIFF）（MRC-MODE = 0）（|（＆（色=バイナリ）（画像符号化= [MH、MR、MMR]）（|（＆（DPI = 204）（ DPI-xyratio = [204/98204/196]））（＆（DPI = 200）（DPI-xyratio = [200 / 100,1]））（＆（DPI = 300）（DPI-xyratio = 1））） （）＆（色=グレー）（色レベル<= 256）（h.QVSEM8V2LMJ8VOR7V682J7079O））（＆（色=フル）（カラーサブサンプリング= [ "1：1：1"、 "4：1：1" ]）（色レベル<= 16777216）（CIELAB-分> = - 85）（CIELAB--MAX <= 85）（CIELAB-B分> = - 75）（CIELAB-B-MAX <= 125）（h.QVSEM8V2LMJ8VOR7V682J7079O）））（サイズX <= 254分の2150）（用紙サイズ= [レター、A4、B4]））（UA-メディア=ステーショナリー））（h.QVSEM8V2LMJ8VOR7V682J7079O）： - （・（画像符号化= JPEG）（画像符号化制約= JPEG-T4E）（色空間= CIELAB）（色光源= D50）（CIELAB-L分> = 0）（CIELAB-L-MAX < = 100）（DPI = [100,200,300]）（DPI-xyratio = 1））終了
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文字列は、現在、US-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 might be to leave this as an application protocol issue (but this could lead to non-interoperable feature sets between different protocols).
しかし、機能セット、構文許可が非US-ASCII文字（例えば、引用符で囲まれた文字列内）の将来の改訂場合、その後、いくつかの標準的な表現は、ハッシュ値を計算する目的のために定義する必要があります。一つの選択肢は、機能セットのハッシュを計算するための基礎としてUTF-8と同等の表現を使用するのが良いかもしれません。もう一つの選択肢は、アプリケーションプロトコルの問題としてこれを残すことかもしれません（これは、異なるプロトコル間の非相互運用可能な機能セットにつながる可能性があります）。
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.
もう一つ考えられるの問題は、のハッシュ値を計算するための準備としての機能発現をアップケースということです。これはそう問題になりそうではありません文字列の内容には適用されません。変更がフィーチャータグまたはトークン文字列内の非US-ASCII文字を許可しないことにしておけばしかし、配慮が適切にケースの変換が実行される方法を定義するために与えられなければなりません。
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.
可能な追加の考慮事項は、手で取引のために必要であるよりも、特定の機能セット識別子の使用は、システムの詳細情報を明らかにすることができるということです。
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、アルギルマンとテッドハーディーとの早期の協議によって改善されました。改善のための有用な提案がマウリツィオコドーニョによって提供されました。
[1] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
[1] "メディア機能セットの記述のための構文" Klyne、G.、RFC 2533を、1999年3月。
[2] Mutz, A. and T. Hardie, "Media Feature Tag Registration Procedure", RFC 2506, March 1999.
[2] MUTZ、A.およびT.ハーディ、 "メディア特徴タグの登録手順"、RFC 2506、1999年3月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[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：インターネットメッセージ本体のフォーマット"、RFC 2045、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、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[6] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[6]リベスト、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[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版）ISBN 0-471-12845-7（布）ISBN 0-471-11709-9（紙）
[8] Klyne, G., "Protocol-independent Content Negotiation Framework", RFC 2703, September 1999.
[8] Klyne、G.、 "プロトコルに依存しないコンテンツネゴシエーションフレームワーク"、RFC 2703、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）ISBN 0 521 30811 9（ガンマ関数の近似は「特殊機能」の章6に提示されている。そこ公表され、この本のいくつかの後の版となっているので、章の参照が変更されることがあります。）
[10] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997.
[10]ダニエル、R.とM. Mealling、 "ドメインネームシステムを使用して統一リソース識別子の決議"、RFC 2168、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/>からリンクされています
Graham Klyne Content Technologies Ltd. 1220 Parkview, Arlington Business Park Theale Reading, RG7 4SA United Kingdom
グラハムKlyneコンテンツテクノロジ株式会社1220パークビュー、アーリントンビジネスパークTheale読書、RG7 4SAイギリス
Phone: +44 118 930 1300 Fax: +44 118 930 1301 EMail: GK@ACM.ORG
電話：+44 118 930 1300ファックス：+44 118 930 1301 Eメール：GK@ACM.ORG
Larry Masinter AT&T Labs 75 Willow Road Menlo Park, CA 94025
ラリーMasinter AT＆T Labsの75ウィローロードメンロパーク、CA 94025
Phone: +1-650-463-7059 EMail: LMM@acm.org http://larry.masinter.net
電話：+ 1-650-463-7059 Eメール：LMM@acm.org http://larry.masinter.net
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.
二つの異なる機能セットが実際に同じハッシュ値が得られることを小さいが明確な可能性があります。
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.
我々は、2 ^ 128（約3×10 ^ 38）の可能な値の範囲を通じてランダムかつ均一に、128ビットのハッシュ関数も、それらの非常に小さな違いが、特徴集合のハッシュ値を分配すると仮定する。これは、MD5のような良いダイジェストアルゴリズムの基本的な特性です。したがって、任意の二つの異なる機能セット表現は、同じハッシュをもたらす可能性が^ 38 10に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.4で詳しく説明し、ブルース・シュナイアーの「応用暗号」の7.5 [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
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]。確率の式は、 'P = 1-（M！/（（MN）！M ^ N））' は 'm' は可能なハッシュ値（2 ^ 128）の合計数であり、 'N' の数であります機能は、使用して設定します。
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.
このすべての結果は次のとおりであっても誕生日パラドックス効果を考慮して、機能セットを手動で生成されると仮定すると、他の可能な故障モードと比較した場合、誤ったハッシュ値を使用して特徴セットを特定する確率は依然として無視できるほど小さいです。
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。