[要約] RFC 2938は、複合メディア機能の識別方法について説明しており、メディアの機能を特定するためのフレームワークを提供しています。このRFCの目的は、異なるメディア機能を識別し、互換性のある通信を可能にするための標準化を促進することです。
Network Working Group G. Klyne
Request for Comments: 2938 Content Technologies
Updates: 2533 L. Masinter
Category: Standards Track AT&T
September 2000
Identifying Composite Media Features
複合メディア機能の識別
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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 2533 [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では、機能セット参照の構文を示し、それらが機能セット式にどのように関連しているかを説明します。
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).
機能セット式式「メディア機能セットを記述するための構文」のルールに従って定式化されたいくつかの機能セットを記述する文字列[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.
o RFC 2533 [1]に準拠するプロトコルプロセッサの場合、その意味の明示的な知識なしに機能セットの参照を容易に処理できるようにすることができます（つまり、機能セット参照の導入は既存の機能式プロセッサを破壊するべきではありません）。つまり、RFC 2533 [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 繰り返されるサブエクスペッションを含むメディア機能の表現。サブ発現が非常に大きい場合は、1回書き出すことでスペースを保存し、省略形式を使用して参照します。
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を参照してください。
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 補助述語（RFC 2533 [1]で導入された）を使用して、機能セット識別子の基礎を形成すること、および
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) )
This specification introduces a special form of auxiliary predicate name with the following syntax:
この仕様では、次の構文を使用して、特別な形式の補助述語名を紹介します。
fname = "h." 1*BASE32DIGIT
BASE32DIGIT = DIGIT
/ "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H"
/ "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P"
/ "Q" / "R" / "S" / "T" / "U" / "V"
The sequence of base-32 digits represents the value of a hash function calculated over the corresponding feature set expression (see following sections). Note that the above syntax allows upper-or lower-case letters for base-32 digits (per RFC 2234 [3]).
ベース32桁のシーケンスは、対応する特徴セット式で計算されたハッシュ関数の値を表します（以下のセクションを参照）。上記の構文では、ベース32桁（RFC 2234 [3]ごと）の上または低ケースの文字が許可されていることに注意してください。
Thus, within a feature set expression, a hashed feature set reference would have the following form:
したがって、機能セット式内で、ハッシュされた機能セットの参照には次の形式があります。
(h.123456789abcdefghijklmnopq)
（h.123456789abcdefghijklmnopq）
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]を使用して計算されます。特徴式は、RFC 2533 [1]の「フィルター」に与えられた構文に適合する必要があります。
filter = "(" filtercomp ")" *( ";" parameter )
The steps for calculating a hash value are:
ハッシュ値を計算するための手順は次のとおりです。
1. Whitespace normalization: all spaces, CR, LF, TAB and any other layout control characters that may be embedded in the feature expression string, other than those contained within quoted strings, are removed (or ignored for the purpose of hash value computation).
1. Whitespaceの正規化：引用された文字列内に含まれるものを除き、機能式式文字列に埋め込まれているすべてのスペース、CR、LF、タブ、およびその他のレイアウト制御文字は削除されます（またはハッシュ値計算の目的で無視されます）。
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値97〜122（小数）を持つ引用されていない文字は、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. ハッシュ計算：RFC 1321 [6]に記載されているMD5アルゴリズムは、正規化された特徴式文字列に適用されます（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で得られた結果は、128ビット（16オクテット）値であり、ベース32表現に変換され、機能セット参照を形成します。
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
"0" 0 "a" 10 "k" 20 "U" 1 "1" 1 "b" 11 "l" 21 "v" 31 "2" 2 "2" "12" m "22" 3 "3" D d"13" n "23" 4 "4" e "14" o "24" 5 "5" f "15" p "25" 6 "" 16 "Q" 26 "7" 7 "7" 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文字のシーケンスで表されます。5オクテット未満のグループがこの後に残っている場合、必要に応じて多くの追加文字を使用してエンコードされます：1、2、3、または4オクテットは、それぞれ2、4、5、または7文字によってエンコードされます。ベース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.
注：base64表現（MIMEごと[4]）はよりコンパクトになります（MD5 128ビットハッシュ値の26文字ではなく21文字）が、補助的な述語名は（[1]によって）定義され、同じ構文を持つと定義されています。機能タグ、および機能タグマッチングルール（[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"を使用します）が、ハッシュ値をエンコードおよびデコードするために拡張精度の乗算と分割操作が必要になるため、使用されませんでした。
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].
次のセクションでは、特徴セットの緩和情報が機能セット式に組み込まれる可能性があるいくつかの方法について説明します。これらは、「Where」条項[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.,
したがって、機能セット識別子で機能に関連付けられているサーバーへのクエリを実行できます。返される応答はコネグ式です。例えば。、
(h.SBB5REAOMHC09CP2GM4V07PQP0)
where
(h.SBB5REAOMHC09CP2GM4V07PQP0) :- (& (pix-x<=200) (pix-y<=150) )
end
or just:
あるいは単に：
(& (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.
このプロセスは、URN解像度メカニズム（DNS NAPTR [10]など）を使用して、解像度プロトコルとサーバーを発見することにより、さらに強化される可能性があります。
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.,
基準値に関連付けられた特徴セット式は、補助述語定義の構文を使用して、「Where」句で直接指定できます[1]。例えば。、
(& (dpi=100) (h.SBB5REAOMHC09CP2GM4V07PQP0) )
where
(h.SBB5REAOMHC09CP2GM4V07PQP0) :- (& (pix-x<=200) (pix-y<=150) )
end
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)
このフォームは、次の行に沿ったシーケンスのフォローアップ応答として使用される可能性があります。A>機能は次のとおりです。SBB5REAOMHC09CP2GM4V07PQP0）
A> Capabilities are:
(& (dpi=100) (h.SBB5REAOMHC09CP2GM4V07PQP0) )
where
(h.SBB5REAOMHC09CP2GM4V07PQP0) :- (& (pix-x<=200)
(pix-y<=150) )
end
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
(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
（color = binary）（paper-size = a4）（image-coding = jbig））end
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) )
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)':
次の例では、フルカラーのインターネットファックスシステムの機能について説明します。注 '（color = gray）'および '（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) )
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
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]の文字のみで構成されるように定義されています。これらの状況下では、この仕様は国際化の考慮事項の影響を受けません（URIS [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文字を許可する場合（たとえば、引用された文字列内）、ハッシュ値を計算する目的でいくつかの標準表現を定義する必要があります。選択肢の1つは、機能セットハッシュを計算するための基礎としてUTF-8等価表現を使用することです。もう1つの選択肢は、これをアプリケーションプロトコルの問題として残すことです（ただし、これは異なるプロトコル間で挿入不可能な機能セットにつながる可能性があります）。
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.
もう1つの考えられる問題は、ハッシュ値を計算するために特徴式をアップケースすることです。これは文字列の内容には適用されないため、問題になる可能性はありません。ただし、機能タグまたはトークン文字列の非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.
ここでのアイデアは、マーティン・デュアースト、アル・ギルマン、テッド・ハーディとの早期議論によって改善されました。改善のための有用な提案は、Maurizio Codognoによって提供されました。
[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. Hardie、「メディア機能タグ登録手順」、RFC 2506、1999年3月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3] Crocker、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] Freed、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] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。
[6] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[6] Rivest、R。、「The Md5 Message-Digest Algorithm」、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・フラナリー、サウル・ア・テウコルスキー、ウィリアム・T・ベッターリング・ケンブリッジ大学出版局（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] Daniel、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
Graham Klyne Content Technologies Ltd. 1220 Parkview、アーリントンビジネスパークシールリーディング、RG7 4SAイギリス
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
Larry Masinter AT＆T Labs 75 Willow Road Menlo Park、CA 94025
Phone: +1-650-463-7059
EMail: 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.
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
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.
上記の確率計算は概算であり、Lanczos [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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。