Network Working Group G. Klyne
Request for Comments: 2533 Content Technologies/5GM
Category: Standards Track March 1999
A Syntax for Describing Media Feature Sets
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 (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1]. A framework for such negotiation is described in [2], part of which is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. A format for a vocabulary of individual media features and procedures for feature registration are presented in [3].
インターネットアプリケーションプロトコルの数が[1]、それらが相互作用するリソースのコンテンツネゴシエーションを提供する必要があります。そのような交渉のためのフレームワークは、に記載されている[2]の部分は、メッセージの送信者、受信者又は文書伝送フォーマットで扱うことができるメディア機能の範囲を記述するための方法です。個々のメディア機能と特徴登録の手順の語彙のためのフォーマットは、[3]に示されています。
This document introduces and describes a syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media feature handling capabilities of message senders, recipients and file formats.
この文書は、個々のメディア機能を含む組み合わせとの関係から形成されている機能セットを定義するために使用できる構文を紹介し、説明しています。このような機能セットは、メッセージの送信者、受信者、およびファイル形式の能力を扱うメディア機能を記述するために使用されています。
An algorithm for feature set matching is also described here.
機能セットのマッチングのためのアルゴリズムは、ここに記載されています。
Table of Contents
目次
1. Introduction.............................................3
1.1 Structure of this document ...........................3
1.2 Document terminology and conventions .................4
1.3 Discussion of this document ..........................4
2. Content feature terminology and definitions..............4
3. Media feature combinations and capabilities..............5
3.1 Media features .......................................5
3.2 Media feature collections and sets ...................5
3.3 Media feature set descriptions .......................6
3.4 Media feature combination scenario ...................7
3.4.1 Data resource options............................7
3.4.2 Recipient capabilities...........................7
3.4.3 Combined options.................................7
3.5 Feature set predicates ...............................8
3.5.1 Comparison with directory search filters.........8
3.6 Describing preferences ...............................9
3.7 Combining preferences ...............................10
4. Feature set representation..............................11
4.1 Textual representation of predicates ................11
4.2 Interpretation of feature predicate syntax ..........12
4.2.1 Filter syntax...................................12
4.2.2 Feature comparison..............................13
4.2.3 Feature tags....................................13
4.2.4 Feature values..................................14
4.2.4.1 Boolean values 14
4.2.4.2 Numeric values 14
4.2.4.3 Token values 15
4.2.4.4 String values 15
4.2.5 Notational conveniences.........................15
4.3 Feature set definition example ......................16
5. Matching feature sets...................................16
5.1 Feature set matching strategy .......................18
5.2 Formulating the goal predicate ......................19
5.3 Replace set expressions .............................19
5.4 Move logical negations inwards ......................20
5.5 Replace comparisons and logical negations ...........20
5.6 Conversion to canonical form ........................21
5.7 Grouping of feature predicates ......................22
5.8 Merge single-feature constraints ....................22
5.8.1 Rules for simplifying ordered values............23
5.8.2 Rules for simplifying unordered values..........23
6. Other features and issues...............................24
6.1 Named and auxiliary predicates ......................24
6.1.1 Defining a named predicate......................24
6.1.2 Invoking named predicates.......................25
6.1.3 Auxiliary predicates in a filter................25
6.1.4 Feature matching with named predicates..........25
6.1.5 Example.........................................26
6.2 Unit designations ...................................26
6.3 Unknown feature value data types ....................27
7. Examples and additional comments........................27
7.1 Worked example ......................................27
7.2 A note on feature tag scoping .......................31
8. Security Considerations.................................34
9. Acknowledgements........................................34
10. References.............................................35
11. Author's Address.......................................36
Full Copyright Statement...................................37
A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1]. A framework for such negotiation is described in [2]. A part of this framework is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message.
インターネットアプリケーションプロトコルの数が[1]、それらが相互作用するリソースのコンテンツネゴシエーションを提供する必要があります。そのような交渉のためのフレームワークは[2]に記載されています。このフレームワークの一部は、メッセージの送信者、受信者又は文書伝送フォーマットで扱うことができるメディア機能の範囲を記述するための方法です。
Descriptions of media feature capabilities need to be based upon some underlying vocabulary of individual media features. A format for such a vocabulary and procedures for registering media features within this vocabulary are presented in [3].
メディア機能機能の説明は、個々のメディア機能のいくつかの基本的な語彙に基づいてする必要があります。この語彙内のメディア機能を登録するためのそのような語彙および手順のためのフォーマットは、[3]に示されています。
This document defines a syntax that can be used to describe feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media handling capabilities of message senders, recipients and file formats.
この文書は、個々のメディア機能を含む組み合わせとの関係から形成されている機能セットを記述するために使用できる構文を定義します。このような機能セットは、メッセージの送信者、受信者、およびファイル形式のメディア処理機能を記述するために使用されています。
An algorithm for feature set matching is also described here.
機能セットのマッチングのためのアルゴリズムは、ここに記載されています。
The feature set syntax is built upon the principle of using feature set predicates as "mathematical relations" which define constraints on feature handling capabilities. This allows that the same form of feature set expression can be used to describe sender, receiver and file format capabilities. This has been loosely modelled on the way that relational databases use Boolean expresions to describe a set of result values, and a syntax that is based upon LDAP search filters.
機能セットの構文は、機能の処理能力に制約を定義し、「数学的関係」として機能セットの述語を使用しての原則に基づいて構築されます。これは、機能セット表現の同じフォームが送信側、受信側とファイルフォーマット機能を記述するために使用することができることを可能にします。これは緩く、リレーショナルデータベースは、結果値のセット、およびLDAP検索フィルタに基づいて構文を記述するために、ブールexpresionsを使用する方法をモデルにされています。
The main part of this memo addresses the following main areas:
このメモの主な部分は、主に以下の分野に対処します。
Section 2 introduces and references some terms which are used with special meaning.
第2節紹介し、参照特別な意味で使用されるいくつかの用語。
Section 3 introduces the concept of describing media handling capabilities as combinations of possible media features, and the idea of using Boolean expressions to express such combinations.
第3節では、可能なメディア機能の組み合わせなどのメディア処理機能を説明する概念、およびそのような組み合わせを表現するブール式を使用してのアイデアを紹介します。
Section 4 contains a description of a syntax for describing feature sets based on the previously-introduced idea of Boolean expressions used to describe media feature combinations.
第4章では、メディア機能の組み合わせを記述するために使用されるブール式の前に導入されたアイデアをもとに機能セットを記述するための構文の記述が含まれています。
Section 5 describes an algorithm for feature set matching.
第5節では、機能セットのマッチングのためのアルゴリズムを説明します。
Section 6 discusses some additional media feature description and processing issues that may be viewed as extensions to the core framework.
セクション6は、コアフレームワークの拡張とみなすことができるいくつかの追加のメディア機能の説明および処理の問題を論じています。
Section 7 contains a worked example of feature set matching, and some additional explanatory comments spurred by issues arising from applying this framework to fascimile transmissions.
第7節は、機能セットのマッチングの加工した例が含まれており、いくつかの追加の説明のコメントはfascimile送信にこのフレームワークを適用から生じる問題に拍車をかけました。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
キーワードは "MUST" は、 "MUST NOT"、 "REQUIRED" は、 "SHOULD" "ないもの" "ものと" べきではありません」、 "推奨"、 "MAY"、および "" OPTIONALこの文書に記載されているにしていますRFC 2119に記載されるように解釈されます。
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.
注：このようなコメントは、この文書の論理的根拠についての追加非必須情報を提供します。このような情報は、準拠の実装を構築するために必要とされていませんが、より深く設計を理解したい人を助けるかもしれません。
Discussion of this document should take place on the content negotiation and media feature registration mailing list hosted by the Internet Mail Consortium (IMC):
本書の議論は、インターネットメールコンソーシアム（IMC）によってホストされているコンテンツのネゴシエーションとメディア特徴登録メーリングリストで行われるべき。
Please send comments regarding this document to:
このドキュメントに関するコメントを送ってください。
ietf-medfree@imc.org
いえｔｆーめｄｆれえ＠いｍｃ。おｒｇ
To subscribe to this list, send a message with the body 'subscribe' to "ietf-medfree-request@imc.org".
このリストを購読するには、「ietf-medfree-request@imc.org」に「購読の体にメッセージを送信します。
To see what has gone on before you subscribed, please see the mailing list archive at:
あなたが加入する前に行っているかを確認するには、でメーリングリストのアーカイブを参照してください。
http://www.imc.org/ietf-medfree/
ｈっｔｐ：／／ｗっｗ。いｍｃ。おｒｇ／いえｔｆーめｄｆれえ／
Feature Collection is a collection of different media features and associated values. This might be viewed as describing a specific rendering of a specific instance of a document or resource by a specific recipient.
機能のコレクションは、さまざまなメディア機能と関連する値の集合です。これは、特定の受信者が文書やリソースの特定のインスタンスの特定のレンダリングを説明するものとして見られるかもしれません。
Feature Set is a set of zero, one or more feature collections.
機能セットは、ゼロ、1以上の特徴のコレクションのセットです。
NOTE: this term is used slightly differently by earlier work on Transparent Content Negotiation in HTTP [4].
注：この用語はHTTPで透明なコンテンツネゴシエーションに以前の仕事により若干異なる使用されている[4]。
Feature set predicate A function of an arbitrary feature collection value which returns a Boolean result. A TRUE result is taken to mean that the corresponding feature collection belongs to some set of media feature handling capabilities defined by this predicate.
特徴は、ブール結果を返す任意の機能のコレクション値の関数を述語設定します。 TRUEの結果は、対応する機能コレクションは、この述語によって定義されたメディア機能の処理機能のいくつかのセットに属することを意味するものと解釈されます。
Other terms used in this memo are defined in [2].
このメモで使用される他の用語は、[2]で定義されています。
This memo assumes that individual media feature values are simple atomic values:
このメモは、個々のメディア機能の値は、単純な原子値であることを前提としています。
o Boolean values.
ブール値は、O。
o Enumerated values.
列挙値O。
o Text string values (treated as atomic entities, like enumerated value tokens).
Oテキスト文字列値は、（列挙値のトークンのような、アトミックエンティティとして扱われます）。
o Numeric values (Integer or rational).
数値（整数または有理数）O。
These values all have the property that they can be compared for equality ('='), and that numeric and ordered enumeration values can be compared for less-than and greater-than relationship ('<=', '>='). These basic comparison operations are used as the primitive building blocks for more comprehensive capability expressions.
これらの値は、すべてのは、彼らが平等（「=」）を比較し、数値のことと列挙値は（「<=」、「> =」）よりも、少ないと大なりの関係を比較することができます注文することができる性質を持っています。これらの基本的な比較操作は、より包括的な機能表現のための原始的なビルディングブロックとして使用されています。
Any single media feature value can be thought of as just one component of a feature collection that describes some instance of a resource (e.g. a printed document, a displayed image, etc.). Such a feature collection consists of a number of media feature tags (each per [3]) and associated feature values.
任意の単一のメディア特徴量は、リソース（例えば、印刷された文書、表示された画像、等）のいくつかのインスタンスを記述する特徴コレクションのようなただ一つのコンポーネントと考えることができます。このような特徴のコレクションは、メディア特徴タグの数と関連する特徴値（[3]あたりそれぞれ）から成ります。
A feature set is a set containing a number of feature collections. Thus, a feature set can describe a number of different data resource instances. These can correspond to different treatments of a single data resource (e.g. different resolutions used for printing a given document), a number of different data resources subjected to a common treatment (e.g. the range of different images that can be rendered on a given display), or some combination of these (see examples below).
機能セットは、フィーチャーコレクションの数を含むセットです。したがって、機能セットは、異なるデータ・リソース・インスタンスの数を記述することができます。これらは、単一のデータ・リソースの異なる処理に対応することができる（例えば、所与の文書の印刷に使用される異なる解像度）（例えば、所与のディスプレイ上にレンダリングすることができる異なる画像の範囲）、共通の処理を施し、異なるデータ・リソースの数をこれらの、またはいくつかの組み合わせ（以下の例を参照）。
Thus, a description of a feature set can describe the capabilities of a data resource or some entity that processes or renders a data resource.
したがって、機能セットの説明は、データリソースまたはデータリソースを処理又はレンダリングするいくつかのエンティティの能力を記述することができます。
A feature set may be unbounded. For example, in principle, there is no limit on the number of different documents that may be output using a given printer. But to be practically useful, a feature set description must be finite.
機能セットは無制限かもしれません。例えば、原理的には、所与のプリンタを用いて出力することができる異なるドキュメントの数に制限はありません。しかし、実用的に有用であることが、機能セットの説明は有限でなければなりません。
The general approach to describing feature sets is to start from the assumption that anything is possible; i.e. the feature set contains all possible document instances (feature collections). Then constraints are applied that progressively remove document instances from this set; e.g. for a monochrome printer, all document instances that use colour are removed, or for a document that must be rendered at some minimum resolution, all document instances with lesser resolutions are removed from the set. The mechanism used to remove document instances from the set is the mathematical idea of a "relation"; i.e. a Boolean function (a "predicate") that takes a feature collection parameter and returns a Boolean value that is TRUE if the feature collection describes an acceptable document instance, or FALSE if it describes one that is excluded.
機能セットを説明する一般的な方法は何が可能であるという仮定から開始することです。すなわち、機能セットは、すべての可能なドキュメントインスタンス（フィーチャーコレクション）が含まれています。そして、制約は徐々にこのセットからドキュメントインスタンスを削除することに適用されます。例えばモノクロプリンタに対してカラーを使用するすべてのドキュメントインスタンスが削除され、またはいくつかの最小解像度でレンダリングされなければならない文書のために、より低い解像度のすべてのドキュメントインスタンスは、セットから除去されます。セットからドキュメントインスタンスを削除するために使用されるメカニズムは、「関係」の数学的な考え方です。すなわち、特徴収集パラメータを受け取り、それを除外したものを記載している場合特徴収集が許容されるドキュメントインスタンスを記述する、またはFALSE場合はTRUEになるブール値を返すブール関数（「述語」）。
P(C)
P(C) = TRUE <- : -> P(C) = FALSE
:
+----------:----------+ This box represents some
| : | set of feature collections (C)
| Included : Excluded | that is constrained by the
| : | predicate P.
+----------:----------+
:
The result of applying a series of such constraints is a smaller set of feature collections that represent some media handling capability. Where the individual constraints are represented by predicates that each describe some media handling capability, the combined effect of these constraints is some subset of the individual constraint capabilities that can be represented by a predicate that is the logical-AND of the individual constraint predicates.
このような制約のシリーズを適用した結果は、一部のメディア処理能力を表すフィーチャーコレクションの小さなセットです。個々の制約はそれぞれ、いくつかのメディア処理能力を記述する述語で表される場合、これらの制約の複合効果は、論理AND個々の制約は述語である述語で表すことができ、個々の制約機能のサブセットです。
This section develops some example scenarios, introducing the notation that is defined formally in section 4.
このセクションは、セクション4で正式に定義されている表記法を導入し、いくつかの例示的なシナリオを開発します。
The following expression describes a data resource that can be displayed either: (a) as a 750x500 pixel image using 15 colours, or (b) at 150dpi on an A4 page.
（a）は、750x500ピクセル15点の色を用いた画像、または（b）のように150dpiでA4ページに以下の式のいずれかを表示することができるデータリソースを記述する。
(| (& (pix-x=750) (pix-y=500) (color=15) ) (& (dpi>=150) (papersize=iso-A4) ) )
（|（＆（PIX-X = 750）（PIX-Y = 500）（色= 15））（＆（DPI> = 150）（用紙サイズ= ISO-A4）））
The following expression describes a receiving system that has: (a) a screen capable of displaying 640*480 pixels and 16 million colours (24 bits per pixel), 800*600 pixels and 64 thousand colours (16 bits per pixel) or 1024*768 pixels and 256 colours (8 bits per pixel), or (b) a printer capable of rendering 300dpi on A4 paper.
640×480ピクセルを表示することができる（a）の画面と16万色（画素あたり24ビット）、800 * 600ピクセルと64万色（画素あたり16ビット）または1024 *：以下の式が有する受信システムが記載されて768ピクセル、256色（画素当たり8ビット）、又は（b）のA4用紙に300dpiのレンダリング可能なプリンタ。
(| (& (| (& (pix-x<=640) (pix-y<=480) (color<=16777216) )
(& (pix-x<=800) (pix-y<=600) (color<=65535) )
(& (pix-x<=1024) (pix-y<=768) (color<=256) ) )
(ua-media=screen) )
(& (dpi=300)
(ua-media=stationery) (papersize=iso-A4) ) )
Note that this expression says nothing about the colour or grey-scale capabilities of the printer. In the scheme presented here, it is presumed to be unconstrained in this respect (or, more realistically, any such constraints are handled out-of-band by anyone sending to this recipient).
この式は、プリンタのカラーまたはグレースケールの機能については何も述べていないことに注意してください。ここに提示方式で、それはこの点にとらわれないことと推定される（または、より現実的に、このような制約は、この受信者に送信する誰もがアウト・オブ・バンド処理されます）。
The following example describes the range of document representations available when the resource described in the first example above is sent to the recipient described in the second example. This is the result of combining their capability feature sets:
上記実施例1で説明したリソースが第二の例で説明した受信者に送信される場合は、次の例では、利用可能なドキュメント表現の範囲が記載されています。これは彼らの能力の機能セットを組み合わせた結果です：
(| (& (pix-x=750) (pix-y=500) (color=15) )
(& (dpi=300) (ua-media=stationery) (papersize=iso-A4) ) )
The feature set described by this expression is the intersection of the sets described by the previous two capability expressions.
この表現で記述機能セットは、前の二つの機能表現で記述セットの共通部分です。
There are many ways of representing a predicate. The ideas in this memo were inspired by the programming language Prolog [5], and its use of predicates to describe sets of objects.
述語を表現する多くの方法があります。このメモでアイディアをプログラミング言語Prologの[5]、およびオブジェクトの集合を記述するための述語の使用に触発されました。
For the purpose of media feature descriptions in networked application protocols, the format used for LDAP search filters [7,8] has been adopted, because it is a good match for the requirements of capability identification, and has a very simple structure that is easy to parse and process.
それは能力特定の要件のために良い試合で、かつ簡単で、非常に簡単な構造を有しているため、ネットワークアプリケーションプロトコルにおけるメディア機能の説明の目的のために、LDAP検索フィルタに使用される形式[7,8]は、採用されています解析し、処理します。
Observe that a feature collection is similar to a directory entry, in that it consists of a collection of named values. Further, the semantics of the mechanism for selecting feature collections from a feature set is in many respects similar to selection of directory entries from a directory.
それは名前付きの値の集合で構成され、その中の特徴のコレクションは、ディレクトリエントリに似ていることを確認します。さらに、機能セットから特徴のコレクションを選択するためのメカニズムのセマンティクスは、ディレクトリからディレクトリエントリの選択に類似した多くの点です。
A feature set predicate used to describe media handling capabilities is implicitly applied to some feature collection. Within the predicate, members of the feature collection are identified by their feature tags, and are compared with known feature values. (Compare with the way an LDAP search filter is applied to a directory entry, whose members are identified by attribute type names, and compared with known attribute values.)
メディア処理機能を記述するために使用される機能セットの述語は、暗黙のうちに、いくつかの機能のコレクションに適用されます。述語内では、フィーチャーコレクションのメンバーは、その機能タグによって識別され、既知の特徴値と比較されています。 （LDAP検索フィルタは、そのメンバーが既知の属性値と比較して属性の型の名前で識別され、ディレクトリエントリに適用される方法と比較してください。）
For example, in:
例えば、中：
(& (dpi>=150) (papersize=iso-A4) )
（＆（DPI> = 150）（用紙サイズ= ISO-A4））
the tokens 'dpi' and 'papersize' are feature tags, and '150' and ' iso-A4' are feature values. (In a corresponding LDAP search filter, they would be directory entry attribute types and attribute values.)
トークン「DPI」と「用紙サイズ」は特徴タグであり、「150」と「ISO-A4」機能値です。 （対応するLDAP検索フィルタでは、彼らは、ディレクトリエントリの属性タイプと属性値になります。）
Differences between directory selection (per [7]) and feature set selection are:
（[7]あたりの）ディレクトリの選択と機能セットの選択の違いは次のとおりです。
o Directory selection provides substring-, approximate- and extensible- matching for attribute values. Such matching is not provided for feature set selection.
Oディレクトリの選択は、属性値のため、substring- approximate-とextensible-マッチングを提供します。このようなマッチングは、機能セットの選択のために提供されていません。
o Directory selection may be based on the presence of an attribute without regard to its value. Within the semantic framework described by this document, Boolean-valued feature tests can be used to provide a similar effect.
Oディレクトリの選択は、その値に関係なく、属性の存在に基づくことができます。この文書によって記述意味論的枠組みの中で、ブール値の機能テストは、同様の効果を提供するために使用することができます。
o Directory selection provides for matching rules that test for the presence or absence of a named attribute type.
Oディレクトリの選択は、名前の属性タイプの有無をテストするルールを一致させるために用意されています。
o Directory selection provides for matching rules which are dependent upon the declared data type of an attribute value.
Oディレクトリの選択は、属性値の宣言されたデータのタイプに依存するルールに一致することを提供します。
o Feature selection provides for the association of a quality value with a feature predicate as a way of ranking the selected value collections.
O機能の選択は、選択した値のコレクションをランク付けする方法として機能述語と品質値の関連性のために用意されています。
Within the semantic framework described by this document, Boolean-valued feature tests can be used where presence tests would be used in a directory search filter.
プレゼンステストは、ディレクトリ検索フィルタで使用されるところ、この文書で説明した意味的な枠組みの中で、ブール値の機能テストを使用することができます。
The idea of extensible matching and matching rules dependent upon data types are facets of a problem not addressed by this memo, but which do not necessarily affect the feature selection syntax. An aspect that might bear on the syntax would be specification of an explicit matching rule as part of a selection expression.
データの種類に依存して拡張可能な一致の考え方と一致するルールは、このメモで扱われていない問題の面ですが、これは必ずしも特徴選択の構文には影響を与えません。構文に耐えるかもしれない側面は、選択式の一部として明示的に一致したルールの仕様になります。
A convenient way to describe preferences is by numeric "quality values".
環境設定を記述するための便利な方法は、数値「品質値」です。
It has been suggested that numeric quality values are potentially misleading if used as more than just a way of ranking options. For the purposes of this memo, ranking of options is sufficient.
オプションをランク付けするだけの方法よりも多くとして使用する場合は、数値の品質値が潜在的に誤解を招きやすいことが示唆されています。このメモの目的のために、オプションのランキングは十分です。
Numeric quality values in the range 0 to 1, with up to 3 fractional digits, are used to rank feature sets according to preference. Higher values are preferred over lower values, and equal values are presumed to be equally preferred. Beyond this, the actual number used has no significance defined here. Arithmetic operations on quality values are likely to produce unpredictable results unless appropriate semantics have been defined for the context where such operations are used.
最大3小数桁範囲内の数値品質値0~1は、好みに応じて特徴セットをランク付けするために使用されます。より高い値はより低い値よりも優先され、同じ値が等しく好適であることが推定されます。これを越えて、使用される実際の数は、ここで定義された意味はありません。適切な意味は、そのような操作が使用されるコンテキストのために定義されていない限り、品質値の算術演算は、予測できない結果を生じる可能性があります。
In the absence of any explicitly applied quality value, a value of "1" is assumed.
明示的に適用される品質値が存在しない場合に、「1」の値が想定されます。
Using the notation defined later, a quality value may be attached to any feature set predicate sub-expression:
後で定義される表記法を使用して、品質値は、任意の機能セット述語サブ式に取り付けられてもよいです。
(| (& (pix-x=750) (pix-y=500) (color=15) );q=0.8 (& (dpi>=150) (papersize=iso-A4) ) ;q=0.7 )
（|（＆（PIX-X = 750）（PIX-Y = 500）（色= 15））; Q = 0.8（＆（DPI> = 150）（用紙サイズ= ISO-A4））; Q = 0.7）
Section 3.7 below explains that quality values attached to sub-expressions are not always useful.
3.7節では、以下のサブ式に取り付けた品質値は必ずしも有用ではないと説明しています。
NOTE: the syntax for quality values used here taken from that defined for HTTP 'Accept:' headers in RFC 2068 [9], section 3.9. However, the use of quality values defined here does not go as far as that defined in RFC 2068.
注：RFC 2068でのヘッダー[9]、セクション3.9：ここで使用されるHTTP用に定義されたものから取られた品質値の構文は、「同意します」。それは、RFC 2068で定義されているようしかし、ここで定義された品質値の使用は限り行きません。
The general problem of describing and combining preferences among feature sets is very much more complex than simply describing allowable feature sets. For example, given two feature sets:
機能セットの中から好みを記述し、組み合わせの一般的な問題は非常にはるかに複雑単に許容機能セットを記述する超えています。例えば、2つの特徴セットを与えられました：
(& (a1);q=0.8 (b1);q=0.7 ) (& (a2);q=0.5 (b2);q=0.9 )
（＆（A1）; Q = 0.8（B1）; Q = 0.7）（＆（a2）は、Q = 0.5（B2）; Q = 0.9）
where: feature a1 is preferred over a2 feature b2 is preferred over b1
ここで、機能A1はA2機能B2よりも好ましいが、B1よりも優先されます
Which of these feature sets is preferred? In the absence of additional information or assumptions, there is no generally satisfactory answer to this.
これらの機能セットのどちらが優先されますか？追加情報や仮定がない場合には、このへの一般的満足のいく答えはありません。
The proposed resolution of this issue is simply to say that no rules are provided for combining preference information. Applied to the above example, any preference information about (a1) in relation to (a2), or (b1) in relation to (b2) is not presumed to convey information about preference of (& (a1) (b1) ) in relation to (& (a2) (b2) ).
この問題の提案された解決は、ルールが嗜好情報を組み合わせるために提供されていないと言うことは、単純です。上記の例に適用し、関連して（＆（A1）（B1））の嗜好に関する情報を伝達するためと推定されていない（a1）と（B2）との関係で（A2）、又は（B1）との関係で約任意嗜好情報（＆（A2）（B2））。
In practical terms, this restricts the application of preference information to top-level predicate clauses. A top-level clause completely defines an allowable feature set; clauses combined by logical-AND operators cannot be top-level clauses (see canonical format for feature set predicates, described later).
実際には、これは、トップレベルの述語句に嗜好情報の適用を制限します。トップレベルの句は、完全に許容可能な機能セットを定義します。論理AND演算子によって結合句は、トップレベルの節（後述する機能セット述部用の標準形式を参照）ことができません。
NOTE: This memo does not apply specific meaning to quality values or rules for combining them. Application of such meanings and rules is not prohibited, but is seen as an area for continuing research and experimentation.
注：このメモはそれらを結合するための品質値や規則に特定の意味を適用しません。そのような意味やルールの適用は禁止されていないが、研究と実験を継続するための領域として見られています。
An example of a design that uses extended quality value semantics and combining operations is "Transparent Content Negotiation in HTTP" [4]. Other work that also extends quality values is the content negotiation algorithm in the Apache HTTP server [14].
拡張された品質値セマンティクスと結合操作を使用する設計の例は、「HTTPに透過的内容ネゴシエーション」である[4]。また、品質値を拡張して他の作業は、Apache HTTPサーバのコンテンツネゴシエーションアルゴリズム[14]です。
The foregoing sections have described a framework for defining feature sets with predicates applied to feature collections. This section presents a concrete representation for feature set predicates.
前述のセクションでは、機能コレクションに適用される述語と機能セットを定義するためのフレームワークを記載しています。このセクションでは、機能セットの述語のための具体的な表現を提示します。
The text representation of a feature set is based on RFC 2254 "The String Representation of LDAP Search Filters" [8], excluding those elements not relevant to feature set selection (discussed above), and adding elements specific to feature set selection (e.g. options to associate quality values with predicates).
機能セットのテキスト表現は、RFC 2254 [8]、（（前述の）セットの選択を特徴に関連していないそれらの要素を除いて、選択セットを搭載した特定の要素を追加するなどのオプション「LDAP検索フィルタの文字列表現」に基づいています述語で品質値を関連付けます）。
The format of a feature predicate is defined by the production for "filter" in the following, using the syntax notation and core rules of RFC 2234 [10]:
特徴述語のフォーマットは、RFC 2234の構文記法とコア規則を使用して、以下では「フィルタ」の生産によって定義されている[10]。
filter = "(" filtercomp ")" *( ";" parameter ) parameter = "q" "=" qvalue / ext-param "=" ext-value qvalue = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] ) ext-param = ALPHA *( ALPHA / DIGIT / "-" ) ext-value = <parameter value, according to the named parameter> filtercomp = and / or / not / item and = "&" filterlist or = "|" filterlist not = "!" filter filterlist = 1*filter item = simple / set / ext-pred set = attr "=" "[" setentry *( "," setentry ) "]" setentry = value "/" range range = value ".." value simple = attr filtertype value filtertype = equal / greater / less equal = "=" greater = ">=" less = "<=" attr = ftag value = fvalue ftag = <Feature tag, as defined in RFC 2506 [3]> fvalue = Boolean / number / token / string Boolean = "TRUE" / "FALSE" number = integer / rational integer = [ "+" / "-" ] 1*DIGIT rational = [ "+" / "-" ] 1*DIGIT "/" 1*DIGIT token = ALPHA *( ALPHA / DIGIT / "-" ) string = DQUOTE *(%x20-21 / %x23-7E) DQUOTE ; quoted string of SP and VCHAR without DQUOTE ext-pred = <Extension constraint predicate, not defined here>
フィルタ= "（" filtercomp "）" *（ ";" パラメータ）パラメータ= "Q" "=" のqvalue / EXT-PARAM "=" EXT値のqvalue =（ "0" [ "" 0 * 3DIGIT]） /（ "1" [0 * 3（ "0"） ""]）EXT-PARAM = ALPHA×（ALPHA / DIGIT / " - "）EXT-値= <パラメータ値が、指定されたパラメータに応じて> filtercomp =および/または/ない/項目および= "＆" filterlistまたは= "|" filterlistありません= "！"フィルタfilterlist = 1 *フィルターアイテム=シンプル/設定/ EXT-predを設定= ATTR "=" "[" setentry×（ "" setentry） "]" setentry =値 "/" レンジ範囲=値 ".." 値簡単= ATTRのfilterType値のfilterType =等しい/大きい/以下等しい= "=" より大きい= "> =" 未満= "<=" ATTR = FTAG値= fvalue FTAG = <特徴タグ、RFC 2506で定義されるように[3]> fvalue =ブール値/数/トークン/文字列、ブール= "TRUE" / "FALSE" 数=整数/有理整数= [ "+" / " - "] 1 * DIGIT合理= [ "+" / " - "] 1 * DIGIT "/" 1つの* DIGITトークン= ALPHA×（ALPHA / DIGIT / " - "）の文字列= DQUOTE *（％x20-21 /％x23-7E）DQUOTE。 DQUOTEのEXT-predは= <ここで定義されていない拡張制約述語、>なしSPとVCHARの引用符で囲まれた文字列
(Subject to constraints imposed by the protocol that carries a feature predicate, whitespace characters may appear between any pair of syntax elements or literals that appear on the right hand side of these productions.)
（特徴述語を運ぶプロトコルによって課される制約を受ける、空白文字は、これらの作品の右側に表示される構文要素又はリテラルの任意の対の間に現れることがあります。）
As described, the syntax permits parameters (including quality values) to be attached to any "filter" value in the predicate (not just top-level values). Only top-level quality values are recognized. If no explicit quality value is given, a value of '1.0' is applied.
説明したように、構文は、述語（だけでなく、最上位の値）の任意の「フィルタ」の値に取り付けられる（品質値を含む）のパラメータを可能にします。唯一のトップレベルの品質の値が認識されています。明示的な品質値が指定されていない場合、「1.0」の値が適用されます。
NOTE: The flexible approach to quality values and other parameter values in this syntax has been adopted for two reasons: (a) to make it easy to combine separately constructed feature predicates, and (b) to provide an extensible tagging mechanism for possible future use (for example, to incorporate a conceivable requirement to explicitly specify a matching rule).
注：この構文で品質値および他のパラメータ値に対する柔軟なアプローチは、2つの理由のために採用されている：（a）に別々に構成特徴述部を結合することを容易にする、および（b）将来使用するために拡張可能なタグ付け機構を提供します（例えば、明示的に一致するルールを指定することが考えられる要件を組み込みます）。
A feature set predicate is described by the syntax production for ' filter'.
機能セットの述語は、「フィルタ」の構文の生産によって記述されています。
A 'filter' is defined as either a simple feature comparison ('item', see below) or a composite filter ('and', 'or', 'not'), decorated with optional parameter values (including "q=qvalue").
「フィルタ」は、単純な機能の比較（「アイテム」、下記を参照）、または複合フィルタのいずれかとして定義（「と」、「または」、「ではない」）、「Q =のqvalue」を含むオプションのパラメータ値（で飾られています）。
A composite filter is a logical combination of one or more 'filter' values:
複合フィルタは、一つ以上の「フィルタ」の値の論理的な組み合わせです。
(& f1 f2 ... fn ) is the logical-AND of the filter values 'f1', 'f2' up to 'fn'. That is, it is satisfied by any feature collection that satisfies all of the predicates represented by those filters.
（＆F1、F2 ... FN） 'FN' へのアップ 'F2'、論理ANDフィルタ値 'F1' です。つまり、これらのフィルタによって表される述語のすべてを満たす任意の特徴のコレクションによって満たされる、です。
(| f1 f2 ... fn ) is the logical-OR of the filter values 'f1', 'f2' up to 'fn'. That is, it is satisfied by any feature collection that satisfies at least one of the predicates represented by those filters.
（| F1、F2 ... FN）は、フィルタ値 'F1'、 'fnの' まで 'F2' の論理和です。つまり、これらのフィルタによって表される述語の少なくとも一つを満たす任意の特徴のコレクションによって満たされる、です。
(! f1 ) is the logical negation of the filter value 'f1'. That is, it is satusfied by any feature collection that does NOT satisfy the predicate represented by 'f1'.
（！F1）フィルタ、値「F1」の論理否定です。つまり、それは「F1」によって表される述語を満たさない任意の特徴のコレクションによって満たされます。
A feature comparison is defined by the 'simple' option of the syntax production for 'item'. There are three basic forms:
機能の比較は、「アイテム」の構文生産の「シンプル」オプションによって定義されます。三つの基本的な形式があります。
(ftag=value) compares the feature named 'ftag' (in some feature collection that is being tested) with the supplied 'value', and matches if they are equal. This can be used with any type of feaure value (numeric, Boolean, token or string).
（FTAG =値）が供給「の値」で（テストされているいくつかの機能のコレクション内）「FTAG」という名前の機能を比較し、それらが等しい場合にマッチします。これはfeaure値（数値、ブール、トークンまたは文字列）のいずれかのタイプを使用することができます。
(ftag<=value) compares the numeric feature named 'ftag' with the supplied 'value', and matches if the feature is less than or equal to 'value'.
（FTAG <=値）が供給された「値」と「FTAG」という数値特徴を比較し、特徴が「値」以下である場合に一致します。
(ftag>=value) compares the numeric feature named 'ftag' with the supplied 'value', and matches if the feature is greater than or equal to 'value'.
（FTAG> =値）が供給された「値」と「FTAG」という数値特徴を比較し、特徴が「値」以上である場合に一致します。
Less-than and greater-than tests may be performed with feature values that are not numeric but, in general, they amount to equality tests as there is no ordering relation on non-numeric values defined by this specification. Specific applications may define such ordering relations on specific feature tags, but such definitions are beyond the scope of (and not required for conformance to) this specification.
この仕様で定義された数値以外の値には順序関係がないように満たないと、テストは一般的には、数値ではなく、ある特徴値を用いて行うことができる大なり、彼らは平等のテストに達します。具体的な用途としては、特定の機能タグに、このような順序関係を定義することが、そのような定義は（と適合するために必要ではない）、この仕様の範囲を超えています。
Feature tags conform to the syntax given in "Media Feature Tag Registration Procedure" [3]. Feature tags used to describe capabilities should be registered using the procedures described in that memo. Unregistered feature tags should be allocated in the "URI tree", as discussed in the media feature registration procedures memo [3].
フィーチャータグは、「メディア特徴タグの登録手順」[3]で与えられた構文に準拠しています。能力を記述するために使用される機能のタグはそのメモに記載されている手順を使用して登録する必要があります。メディア特徴登録手順メモで説明したように未登録の特徴タグは、「URIツリー」に割り当てられるべきである[3]。
If an unrecognized feature tag is encountered in the course of feature set predicate processing, it should be still be processed as a legitimate feature tag. The feature set matching rules are designed to allow new feature tags to be introduced without affecting the validity of existing capability assertions.
認識されていない機能タグが機能セットの述語処理の過程で発生した場合、それはまだ正当な機能タグとして処理されるべきです。機能セットのマッチングルールが新機能タグは、既存の機能アサーションの有効性に影響を与えずに導入できるように設計されています。
A feature may have a number, Boolean, token or string value.
機能は、数値、ブール、トークンまたは文字列値を有することができます。
A Boolean is simply a token with two predefined values: "TRUE" and "FALSE". (Upper- or lower- case letters may be used in any combination.)
「TRUE」と「FALSE」：ブールは、単に2つの定義済みの値を持つトークンです。 （大文字または小文字の文字が任意の組み合わせで使用してもよいです。）
A numeric value is either a decimal integer, optionally preceded by a "+" or "-" sign, or rational number.
「 - 」記号、または有理数数値は、必要に応じて、「+」またはが前の10進整数のいずれかです。
A rational number is expressed as "n/m", optionally preceded by a "+" or "-" sign. The "n" and "m" are unsigned decimal integers, and the value represented by "n/m" is "n" divided by "m". Thus, the following are all valid representations of the number 1.5:
「 - 」記号有理数は、必要に応じて、「+」またはが先行「N / M」として表現されます。 「N」および「M」は、符号なし10進整数であり、「N / M」で表される値であり、「n」は「M」で割りました。したがって、以下では数1.5のすべての有効な表現は、次のとおりです。
3/2 +15/10 600/400
３／２ ＋１５／１０ ６００／４００
Thus, several rational number forms may express the same value. A canonical form of rational number is obtained by finding the highest common factor of "n" and "m", and dividing both "n" and "m" by that value.
したがって、いくつかの合理的な数の形は同じ値を表現することができます。有理数の標準形式は、「N」および「M」の最大公約数を求めると、その値によって「n」および「m」の両方を分割することにより得られます。
A simple integer value may be used anywhere in place of a rational number. Thus, we have:
単純な整数値は、合理的な番号の代わりにどこでも使用することができます。したがって、我々は持っています：
+5 is equivalent to +5/1 or +50/10, etc. -2 is equivalent to -2/1 or -4/2, etc.
+5等、+5/1または+50/10に相当し-2等、又は-2/1 -4/2と等価です
Any sign in a rational number must precede the entire number, so the following are not valid rational numbers:
以下は、有効な有理数ではありませんので、合理的な数の任意の記号は、全体の番号の前にする必要があります。
3/+2, 15/-10 (**NOT VALID**)
3 / + 2、15 / -10（**無効）
A token value is any sequence of letters, digits and '-' characters that conforms to the syntax for 'token' given above. It is a name that stands for some (unspecified) value.
トークン値は、文字、数字、任意の配列である「 - 」「トークン」は、上記所与の構文に準拠した文字。これは、いくつかの（未指定）値の略名です。
A string value is any sequence of characters enclosed in double quotes that conform to the syntax for 'string' given above.
文字列値は、上記の「文字列」の構文に準拠して、二重引用符で囲まれた任意の文字列です。
The semantics of string defined by this memo are the same as those for a token value. But a string allows a far greater variety of internal formats, and specific applications may choose to interpret the content in ways that go beyond those given here. Where such interpretation is possible, the allowed string formats and the corresponding interpretations should be indicated in the media feature registration (per RFC 2506 [3]).
このメモで定義された文字列の意味はトークン値と同じです。しかし、文字列は、内部フォーマットのはるかに大きな多様性を可能にし、特定のアプリケーションは、ここに与えられたものを越えて行く方法でコンテンツを解釈することもできます。そのような解釈が可能であり、許可された文字列形式と対応する解釈がメディア特徴登録（RFC 2506あたりの[3]）に示されるべきです。
The 'set' option of the syntax production for 'item' is simply a shorthand notation for some common situations that can be expressed using 'simple' constructs. Occurrences of 'set' items can eliminated by applying the following identities:
「アイテム」の構文生産の「設定」オプションは、単に「シンプル」構築物を用いて表現することができるいくつかの一般的な状況のための省略表記です。 「セット」項目の出現は、次のアイデンティティを適用することで解消することができます：
T = [ E1, E2, ... En ] --> (| (T=[E1]) (T=[E2]) ... (T=[En]) ) (T=[R1..R2]) --> (& (T>=R1) (T<=R2) ) (T=[E]) --> (T=E)
T = [E1、E2、...] - >（|（T = [E1]）（T = [E 2]）...（T = [A]））（T = [R1..R2 ]） - >（＆（T> = R 1）（T <= R 2））（T = [E]） - >（T = E）
Examples:
例：
The expression: ( paper-size=[A4,B4] ) can be used to express a capability to print documents on either A4 or B4 sized paper.
式：（用紙サイズは= [A4、B4]）はA4またはB4サイズの用紙のいずれかに文書を印刷する機能を発現するために使用することができます。
The expression: ( width=[4..17/2] ) might be used to express a capability to print documents that are anywhere between 4 and 8.5 inches wide.
式：（幅= [4..17 / 2]）はどこでも4〜8.5インチの間の幅である文書を印刷する機能を発現するために使用されるかもしれません。
The set construct is designed so that enumerated values and ranges can be combined in a single expression, e.g.: ( width=[3,4,6..17/2] )
列挙値および範囲を単一の発現、例えば：で組み合わせることができるように設定された構築物が設計されている（幅= [3,4,6..17 / 2]）
The following is an example of a feature predicate that describes a number of image size and resolution combinations, presuming the registration and use of 'Pix-x', 'Pix-y', 'Res-x' and 'Res-y' feature tags:
以下は、「PIX-X」、「PIX-Y」、「RES-X」と「のRE-Y」フィーチャの登録および使用を前提と、画像サイズと解像度の組み合わせの数を記述する特徴述語の一例ですタグ：
(| (& (Pix-x=1024)
（|（＆（PIX-X = 1024）
(Pix-y=768) (| (& (Res-x=150) (Res-y=150) ) (& (Res-x=150) (Res-y=300) ) (& (Res-x=300) (Res-y=300) ) (& (Res-x=300) (Res-y=600) ) (& (Res-x=600) (Res-y=600) ) ) ) (& (Pix-x=800) (Pix-y=600) (| (& (Res-x=150) (Res-y=150) ) (& (Res-x=150) (Res-y=300) ) (& (Res-x=300) (Res-y=300) ) (& (Res-x=300) (Res-y=600) ) (& (Res-x=600) (Res-y=600) ) ) ) ;q=0.9 (& (Pix-x=640) (Pix-y=480) (| (& (Res-x=150) (Res-y=150) ) (& (Res-x=150) (Res-y=300) ) (& (Res-x=300) (Res-y=300) ) (& (Res-x=300) (Res-y=600) ) (& (Res-x=600) (Res-y=600) ) ) ) ;q=0.8 )
（PIX-Y = 768）（|（＆（RES-X = 150）（RES-Y = 150））（＆（RES-X = 150）（RES-Y = 300））（＆（RES-X = 300）（RES-Y = 300））（＆（RES-X = 300）（RES-Y = 600））（＆（RES-X = 600）（RES-Y = 600））））（＆（PIX -x = 800）（PIX-Y = 600）（|（＆（RES-X = 150）（RES-Y = 150））（＆（RES-X = 150）（RES-Y = 300））（＆ （RES-X = 300））（= 300-Y RES）（＆（RES-X = 300）（RES-Y = 600））（＆（RES-X = 600）（RES-Y = 600））） ）; Q = 0.9（＆（PIX-X = 640）（PIX-Y = 480）（|（＆（RES-X = 150）（RES-Y = 150））（＆（RES-X = 150）（ RES-Y = 300））（＆（RES-X = 300）（RES-Y = 300））（＆（RES-X = 300）（RES-Y = 600））（＆（RES-X = 600） （RES-Y = 600））））; Q = 0.8）
This section presents a procedure for combining feature sets to determine the common feature collections to which they refer, if there are any. Making a selection from the possible feature collections (based on q-values or otherwise) is not covered here.
このセクションでは、いずれかが存在する場合、それらが参照する共通の特徴のコレクションを決定するための機能セットを組み合わせるための手順を説明します。 （Q値またはその他に基づいて）可能な特徴のコレクションから選択を作ることはここではカバーされていません。
Matching a feature set to some given feature collection is essentially very straightforward: the feature set predicate is simply evaluated for the given feature collection, and the result (TRUE or FALSE) indicates whether the feature collection matches the capabilities, and the associated quality value can be used for selecting among alternative feature collections.
機能セットの述語は、単に与えられた特徴のコレクションのために評価され、（TRUEまたはFALSE）の結果は、機能のコレクションは能力と一致するかどうかを示し、関連する品質値は次のことができますいくつかの特定の機能のコレクションに設定された特徴を一致させることは、本質的に非常に簡単です別の特徴のコレクションの中から選択するために使用されます。
Matching a feature set to some other feature set is less straightforward. Here, the problem is to determine whether or not there is at least one feature collection that matches both feature sets (e.g. is there an overlap between the feature capabilities of a given file format and the feature capabilities of a given recipient?)
他のいくつかの機能セットに設定された特徴をマッチングすることはそれほど簡単です。ここで、問題は、両方の機能セットと一致する少なくとも1つの特徴集合があるか否かを決定することである（例えば、特定のファイル形式の特徴機能と、所与の受信者の特徴機能の間に重複があります？）
This feature set matching is accomplished by logical manipulation of the predicate expressions as described in the following sub-sections.
この機能セットのマッチングは、以下のサブセクションで説明するように述語表現の論理的操作によって達成されます。
For this procedure to work reliably, the predicates must be reduced to a canonical form. The canonical form used here is "disjunctive normal form". A syntax for disjunctive normal form is:
この手順が確実に機能するためには、述語は正規形にしなければなりません。ここで使用される標準的な形式は、「選言標準形」です。選言標準形の構文は次のとおりです。
filter = orlist orlist = "(" "|" andlist ")" / term andlist = "(" "&" termlist ")" / term termlist = 1*term term = "(" "!" simple ")" / simple
フィルタ= Orlia Orlia = "（" "|" 顔 "）" /用語の顔= "（" "＆" アートの用語 "）" /用語用語リスト= 1 *長期ターム= "（" "" シンプル "）" /シンプル
where "simple" is as described previously in section 4.1. Thus, the canonicalized form has at most three levels: an outermost "(|...)" disjunction of "(&...)" conjunctions of possibly negated feature value tests.
4.1節で前述したようにここで、「シンプル」です。このように、正規化形式は、ほとんどの3つのレベルであります。一番外側|可能性が否定特徴値テストの接続詞「（＆...）」の「（...）」論理和を。
NOTE: The usual canonical form for predicate expressions is "clausal form". Procedures for converting general predicate expressions are given in [5] (section 10.2), [11] (section 2.13) and [12] (section 5.3.2).
注：述語表現するための通常の正規の形式は「clausalフォーム」です。一般的な述語表現を変換するための手順は、[5]（セクション10.2）、[11]（セクション2.13）および[12]（セクション5.3.2）に記載されています。
"Clausal form" for a predicate is similar to "conjunctive normal form" for a proposition, being a conjunction (logical AND) of disjunctions (logical ORs). The related form used here, better suited to feature set matching, is "disjunctive normal form", which is a logical disjunction (OR) of conjunctions (ANDs). In this form, the aim of feature set matching is to show that at least one of the disjunctions can be satisfied by some feature collection.
述語は、「Clausal形態」選言（論理和）の（論理積）関連している、命題は、「連言標準形」に類似しています。ここで使用される関連する形式は、セットマッチングを特徴に適し、接続詞（論理積）の論理和（OR）である「選言標準形」です。このフォームでは、機能セットのマッチングの目的は、選言の少なくとも一つは、いくつかの機能のコレクションによって満たすことができることを示すことです。
Is this consideration of canonical forms really required? After all, the feature predicates are just Boolean expressions, aren't they? Well, no: a feature predicate is a Boolean expression containing primitive feature value tests (comparisons), represented by 'item' in the feature predicate syntax. If these tests could all be assumed to be independently TRUE or FALSE, then each could be regarded as an atomic proposition, and the whole predicate could be dealt with according to the (relatively simple) rules of Propositional Calculus.
標準的な形のこの考察は本当に必要ですか？結局のところ、機能の述語は、単なるブール式であるそうではありませんか？まあ、ない：機能述語が機能述語構文で「アイテム」で表すプリミティブ特徴量試験（比較）を含むブール式ではありません。これらのテストは、すべて独立にTRUEまたはFALSEであると仮定することができた場合には、それぞれが、原子命題とみなすことができ、全体の述語は、命題論理の（比較的単純な）規則に従って扱うことができました。
But, in general, the same feature tag may appear in more than one predicate 'item', so the tests cannot be regarded as independent. Indeed, interdependence is needed in any meaningful application of feature set matching, and it is important to capture these dependencies (e.g. does the set of resolutions that a sender can supply overlap the set of resolutions that a recipient can handle?). Thus, we have to deal with elements of the Predicate Calculus, with some additional rules for algebraic manipulation.
しかし、一般的には、同一の特徴タグは、複数の述語「アイテム」に表示される場合がありますので、テストは独立したとみなすことはできません。実際、相互依存は、機能セットのマッチングのいずれかの意味のあるアプリケーションで必要な、（例えば、送信者が供給できる解像度のセットは、受信者が扱うことができる解像度のセットが重複していますか？）これらの依存関係をキャプチャすることが重要です。したがって、我々は、代数的操作のためのいくつかの追加の規則で、述語微積分の要素に対処する必要があります。
A description of both the Propositional and Predicate calculi can be found in [12].
命題と述語結石の両方の説明は、[12]に見出すことができます。
We aim to show that these additional rules are more unfamiliar than complicated. The construction and use of feature predicates actually avoids some of the complexity of dealing with fully-generalized Predicate Calculus.
我々は、これらの追加のルールが複雑よりも慣れていないことを示すために目指しています。機能述語の構築および使用は、実際には完全に一般的な述語計算を扱うの複雑さのいくつかを回避することができます。
The overall strategy for matching feature sets, expanded below, is:
機能セットをマッチングするための総合的な戦略は、以下の拡張され、次のとおりです。
3. Move logical negations "inwards", so that they are all applied directly to feature comparisons.
彼らはすべての比較を特色に直接適用されるように、3、「内側」論理否定を移動します。
4. Eliminate logical negations, and express all feature comparisons in terms of just four comparison operators
4.論理否定を排除し、わずか4つの比較演算子の面ですべての機能比較を表現
5. Reduce the hypothesis to canonical disjunctive normal form (a disjunction of conjunctions).
5.正規選言標準形（論理積の論理和）に対する仮説を減らします。
6. For each of the conjunctions, attempt to show that it can be satisfied by some feature collection.
接続詞の各6.、それはいくつかの機能のコレクションによって満たすことができることを示すためにしよう。
6.1 Separate the feature value tests into independent feature groups, such that each group contains tests involving just one feature tag. Thus, no predicate in a feature group contains a feature tag that also appears in some other group.
6.1各グループはただ1個の特徴タグを含む試験が含まれているように、独立した機能グループに特徴値テストを区切ります。このように、機能群では述語も、他のいくつかのグループに表示された特徴タグが含まれていません。
6.2 For each feature group, merge the various constraints to a minimum form. This process either yields a reduced expression for the allowable range of feature values, or an expression containing the value FALSE, which is an indication that no combination of feature values can satisfy the constraints (in which case the corresponding conjunction can never be satisfied).
各特徴グループについては6.2、最小のフォームに様々な制約をマージします。このプロセスは、特徴値の許容範囲、又は特徴値のいかなる組み合わせが（対応する組み合わせが満足することはできませんその場合に）制約を満たすことができないことを示す値FALSEを含む発現のための発現低下をもたらすいずれか。
7. If the remaining disjunction contains at least one satisfiable conjunction, then the constraints are shown to be satisfiable.
7.残りの和が少なくとも一つの充足組み合わせが含まれている場合、制約が充足可能であることが示されています。
The final expression obtained by this procedure, if it is non-empty, can be used as a statement of the resulting feature set for possible further matching operations. That is, it can be used as a starting point for combining with additional feature set constraint predicate to determine a feature set that is constrained by the capabilities of several entities in a message transfer path.
それが空でない場合は、この手順によって得られた最終的な発現が、可能さらにマッチング動作のために設定され、得られた特徴のステートメントとして使用することができます。つまり、メッセージ転送経路におけるいくつかのエンティティの能力によって制約される機能セットを決定するために、追加の機能セット制約述語と組み合わせるための出発点として使用することが可能です。
NOTE: as presented, the feature matching process evaluates (and stores) all conjunctions of the disjunctive normal form before combining feature tag comparisons and eliminating unsatisfiable conjunctions. For low-memory systems an alternative approach is possible, in which each normal form conjunction is enumerated and evaluated in turn, with only those that are satisfiable being retained for further use.
注：提示されるように、特徴タグの比較を組み合わせ、充足不能接続詞を除去する前に、特徴照合処理評価する（格納）選言標準形のすべての接続詞。低メモリシステムのための別のアプローチは、さらなる使用のために保持されて充足されているのみで、ここで、各正規形の組み合わせが列挙され、順番に評価し、可能です。
A formal statement of the problem we need to solve can be given as: given two feature set predicates, '(P x)' and '(Q x)', where 'x' is some feature collection, we wish to establish the truth or otherwise of the proposition:
私たちが解決する必要がある問題の正式な声明は次のように与えられる2つの機能セットの述語、「X」いくつかの機能の集まりである「（P x）から」と「（Q xを）」、与えられた、私たちは真実を確立したいですあるいは命題の：
EXISTS(x) : (P x) AND (Q x)
EXISTS（x）は：（P x）からAND（Q x）から
i.e. does there exist a feature collection 'x' that satisfies both predicates, 'P' and 'Q'?
すなわち、両方の述部を満たす機能コレクション「X」、「P」と「Q」は存在しませんか？
Then, if feature sets to be matched are described by predicates 'P' and 'Q', the problem is to determine if there is any feature set satisfying the goal predicate:
機能セットは、述語「P」及び「Q」によって記載されて一致する場合、問題は、目標述語を満たす任意の機能セットがあるかどうかを決定することです。
(& P Q)
（＆P Q）
i.e. to determine whether the set thus described is non-empty.
すなわち、このように説明したセットが空であるかどうかを判断します。
Replace all "set" instances in the goal predicate with equivalent "simple" forms:
：同等の「シンプル」の形でゴール述語内のすべての「設定」のインスタンスを置き換えます
T = [ E1, E2, ... En ] --> (| (T=[E1]) (T=[E2]) ... (T=[En]) ) (T=[R1..R2]) --> (& (T>=R1) (T<=R2) ) (T=[E]) --> (T=E)
T = [E1、E2、...] - >（|（T = [E1]）（T = [E 2]）...（T = [A]））（T = [R1..R2 ]） - >（＆（T> = R 1）（T <= R 2））（T = [E]） - >（T = E）
The goal of this step is to move all logical negations so that they are applied directly to feature comparisons. During the following step, these logical negations are replaced by alternative comparison operators.
このステップの目標は、彼らが比較を特徴とする直接適用されるように、すべての論理否定を移動することです。次のステップの間に、これらの論理否定は代替比較演算子に置き換えられます。
This is achieved by repeated application of the following transformation rules:
これは、次の変換ルールを繰り返し適用することにより達成されます。
(! (& A1 A2 ... Am ) ) --> (| (! A1 ) (! A2 ) ... (! Am ) ) (! (| A1 A2 ... Am ) ) --> (& (! A1 ) (! A2 ) ... (! Am ) ) (! (! A ) ) --> A
（！（＆A1 A2 ...アム）） - >（|！（A1）（A2）...（アム）！！）（（|！A1 A2 ...アム）） - >（＆ ...（アム！）））（A1！）（A2！）（（A！！） - > A
The first two rules are extended forms of De Morgan's law, and the third is elimination of double negatives.
最初の2つのルールがド・モルガンの法則の形式を拡張され、そして第三は、二重否定の除去です。
The predicates are derived from the syntax described previously, and contain primitive value testing functions '=', '<=', '>='. The primitive tests have a number of well known properties that are exploited to reach a useful conclusion; e.g.
述語は、構文から誘導される前述の、および「=」、「<=」、「> =」プリミティブ値のテスト機能を含みます。原始的なテストでは、便利な結論に到達するために利用されて良く知られた特性の数を持っています。例えば
(A = B) & (B = C) => (A = C) (A <= B) & (B <= C) => (A <= C)
（A = B）＆（B = C）=>（A = C）（<= B）＆（B <= C）=>（<= C）
These rules form a core body of logic statements against which the goal predicate can be evaluated. The form in which these statements are expressed is important to realizing an effective predicate matching algorithm (i.e. one that doesn't loop or fail to find a valid result). The first step in formulating these rules is to simplify the framework of primitive predicates.
これらのルールは、目標述語を評価することができ、それに対して、論理ステートメントのコア体を形成します。これらのステートメントが発現される形態は、有効な述語マッチングアルゴリズム（ループしないか、有効な結果を見つけることができない、すなわち1）を実現するために重要です。これらのルールを策定する最初のステップは、プリミティブ述の枠組みを簡素化することです。
The primitive predicates from which feature set definitions are constructed are '=', '<=' and '>='. Observe that, given any pair of feature values, the relationship between them must be exactly one of the following:
セット定義が構成されていますそこからプリミティブ述語は「=」、「<=」と「> =」です。特徴値の任意のペア与えられ、それらの間の関係は、以下の正確に一つでなければならない、ことを確認：
(LT a b): 'a' is less than 'b'. (EQ a b): 'a' is equal to 'b'. (GT a b): 'a' is greater than 'b'. (NE a b): 'a' is not equal to 'b', and is not less than or greater than 'b'.
（B LT）： '' 'B' よりも小さいです。 （EQ B）： '' 'B' に等しいです。 （GT B）： '' 'B' よりも大きいです。 （NE B）：「」「B」に等しくなく、以下「B」よりも大きくありません。
(The final case arises when two values are compared for which no ordering relationship is defined, and the values are not equal; e.g. two unequal string values.)
（最終的なケースは、2つの値を比較したとき何の順序関係が定義されていない、との値が等しくないれているために生じる、例えば2つの等しくない文字列値）。
These four cases can be captured by a pair of primitive predicates:
これらの4例は、原始的な述語の組で捕捉することができます。
(LE a b): 'a' is less than or equal to 'b'. (GE a b): 'a' is greater than or equal to 'b'.
（LE B）は：「」「B」以下です。 （GE B）は：「」「B」以上です。
The four cases described above are prepresented by the following combinations of primitive predicate values:
上記説明した4つのケースがプリミティブ述語値の次の組み合わせによって表されます。
(LE a b) (GE a b) | relationship
----------------------------------
TRUE FALSE | (LT a b)
TRUE TRUE | (EQ a b)
FALSE TRUE | (GT a b)
FALSE FALSE | (NE a b)
Thus, the original 3 primitive tests can be translated to combinations of just LE and GE, reducing the number of additional relationships that must be subsequently captured:
したがって、元の3つのプリミティブテストはその後捕捉されなければならない追加的な関係の数を減らすだけでLEとGEの組み合わせに変換することができます。
(a <= b) --> (LE a b) (a >= b) --> (GE a b) (a = b) --> (& (LE a b) (GE a b) )
（<= B） - >（LE B）（> = B） - >（GE B）（A = B） - >（＆（LE B）（GE B））
Further, logical negations of the original 3 primitive tests can be eliminated by the introduction of 'not-greater' and 'not-less' primitives
さらに、元の3つのプリミティブテストの論理否定は、「未大きく」と「レスない」プリミティブを導入することによって解消することができます
(NG a b) == (! (GE a b) ) (NL a b) == (! (LE a b) )
（NG B）==（！（GE B））（NL B）==（！（LE B））
using the following transformation rules:
以下の変換規則を使用して：
(! (a = b) ) --> (| (NL a b) (NG a b) ) (! (a <= b) ) --> (NL a b) (! (a >= b) ) --> (NG a b)
（！（A = B）） - >（|（NL AB）（NG AB））（！（A <= B）） - >（NL AB） - >（（A> = B）！） （NG AB）
Thus, we have rules to transform all comparisons and logical negations into combinations of just 4 relational operators.
したがって、私たちは4の関係演算子の組み合わせの中にすべての比較と論理否定を変換するためのルールを持っています。
NOTE: Logical negations have been eliminated in the previous step.
注：論理否定は、前のステップで除去されています。
Expand bracketed disjunctions, and flatten bracketed conjunctions and disjunctions:
括弧選言を展開し、括弧接続詞および選言をフラット化：
(& (| A1 A2 ... Am ) B1 B2 ... Bn ) --> (| (& A1 B1 B2 ... Bn ) (& A2 B1 B2 ... Bn ) : (& Am B1 B2 ... Bn ) ) (& (& A1 A2 ... Am ) B1 B2 ... Bn ) --> (& A1 A2 ... Am B1 B2 ... Bn ) (| (| A1 A2 ... Am ) B1 B2 ... Bn ) --> (| A1 A2 ... Am B1 B2 ... Bn )
（＆（| A1 A2 ...アム）のB1 B2 ... BN） - >（|（＆A1 B1はB2 ... BN）（＆A2 B1 B2 ... BN）：（＆アムB1はB2。 ... BN））（＆（＆A1 A2 ...アム）のB1 B2 ... BN） - >（＆A1 A2 ...アムB1はB2 ... BN）（|（| A1 A2 ...午前）のB1 B2 ... BN） - >（| A1 A2 ...午前B1をB2 ... BN）
The result is in "disjunctive normal form", a disjunction of conjunctions:
その結果は、「選言標準形」で接続詞の論理和であります：
(| (& S11 S12 ... ) (& S21 S22 ... ) : (& Sm1 Sm2 ... Smn ) )
（|（＆S11 S12 ...）（＆S21 S22 ...）：（＆Sm1とSm2を... SMN））
where the "Sij" elements are simple feature comparison forms constructed during the step at section 5.5. Each term within the top-level "(|...)" construct represents a single possible feature set that satisfies the goal. Note that the order of entries within the top-level '(|...)', and within each '(&...)', is immaterial.
ここで、「Sijと」の要素は、セクション5.5でのステップの間に構築され、単純な機能の比較形態です。トップレベル「（| ...）」内の各用語は、構築物は、目標を満たす単一の可能な機能セットを表します。 、および内の各「（＆...）」、重要ではない|トップレベルの「（...）」内のエントリの順序があることに注意してください。
From here on, each conjunction '(&...)' is processed separately. Only one of these needs to be satisfiable for the original goal to be satisfiable.
ここでからは、各組み合わせは「（＆...」）別々に処理されます。当初の目標を満足できるようにするためにのみ、これらのニーズの一つが満足できることにします。
(A textbook conversion to clausal form [5,11] uses slightly different rules to yield a "conjunctive normal form".)
（clausal形態に教科書変換[5,11]「は連言標準形」を得るために、わずかに異なるルールを使用します）。
NOTE: Remember that from here on, each conjunction is treated
separately.
Each simple feature predicate contains a "left-hand" feature tag and a "right-hand" feature value with which it is compared.
それぞれの簡単な機能の述語は「左手」機能タグと、それが比較されると、「右」機能値が含まれています。
To arrange these into independent groups, simple predicates are grouped according to their left hand feature tag ('f').
独立したグループにこれらを整理するには、簡単な述語は、その左側の機能タグ（「F」）に従ってグループ化されています。
Within each group, apply the predicate simplification rules given below to eliminate redundant single-feature constraints. All single-feature predicates are reduced to an equality or range constraint on that feature, possibly combined with a number of non-equality statements.
各グループ内で、冗長な単一機能の制約を排除するために下記の述語簡略化規則を適用します。すべての単一機能の述語は、おそらく非平等文の数と組み合わせて、その機能上の平等や範囲の制約、に還元されます。
If the constraints on any feature are found to be contradictory (i.e. resolved to FALSE according to the applied rules), the containing conjunction is not satisfiable and may be discarded. Otherwise, the resulting description is a minimal form of that particular conjunction of the feature set definition.
任意の機能上の制約が（すなわち、適用されるルールに従ってFALSEに解決）矛盾であることが判明している場合は、含有する組み合わせが充足されず、廃棄されてもよいです。そうでなければ、結果として得られる記述は、特徴セット定義の特定の組み合わせの最小形です。
These rules are applicable where there is an ordering relationship between the given values 'a' and 'b':
与えられた値「a」と「b」間の順序関係がある場合、これらのルールが適用されます。
(LE f a) (LE f b) --> (LE f a), a<=b (LE f b), otherwise (LE f a) (GE f b) --> FALSE, a<b (LE f a) (NL f b) --> FALSE, a<=b (LE f a) (NG f b) --> (LE f a), a<b (NG f b), otherwise
（LE FA）（LEのFB） - >（LE FA）、<= bの（LEのFB）、そうでない場合は（LE FA）（GEのFB） - > FALSE、<B（LE FA）（NL FB） - > FALSE、<= bの（LE FA）（NGのFB） - >（LE FA）、<B（NGのFB）、さもなければ
(GE f a) (GE f b) --> (GE f a), a>=b (GE f b), otherwise (GE f a) (NL f b) --> (GE f a) a>b (NL f b), otherwise (GE f a) (NG f b) --> FALSE, a>=b
（GE FA）（GEのFB） - >（GE FA）、A> = B（GEのFB）、そうでなければ（GE FA）（NL FB） - >（GE FA）A> B（NL FB）、さもなければ（GE FA）（NG FB） - > FALSE、A> = B
(NL f a) (NL f b) --> (NL f a), a>=b (NL f b), otherwise (NL f a) (NG f b) --> FALSE, a>=b
> FALSE、A> = B - そうでなければ、A> = B（NL F b）は、（NGのF b）は（A F NL）>（A F NL） - （NL F b）は（A F NL）
(NG f a) (NG f b) --> (NG f a), a<=b (NG f b), otherwise
（FのA）〜（F b）は - >（F NG）、<= bの（F b）は、そうでなければ
These rules are applicable where there is no ordering relationship applicable to the given values 'a' and 'b':
与えられた値「a」と「b」に適用順序付け関係がないところこれらの規則は適用されます。
(LE f a) (LE f b) --> (LE f a), a=b FALSE, otherwise (LE f a) (GE f b) --> FALSE, a!=b (LE f a) (NL f b) --> (LE f a) a!=b FALSE, otherwise (LE f a) (NG f b) --> (LE f a), a!=b FALSE, otherwise
（OD）（FB） - >（OD）、A = B FALSE、そうでない場合は（IE）（地理FB） - > FALSE、B =（OD）（NL FB）！ - > （OD）= B FALSE、そうでない場合（IE）（NGのFB） - ！>（OD）、B = FALSE、そうでない場合
(GE f a) (GE f b) --> (GE f a), a=b FALSE, otherwise (GE f a) (NL f b) --> (GE f a) a!=b FALSE, otherwise (GE f a) (NG f b) --> (GE f a) a!=b FALSE, otherwise
（GE FA）（GEのFB） - >（GE FA）、B = FALSE、そうでなければ（GE FA）（NLのFB） - >（GE FA）= B（そうでなければ（GE FA）、FALSE NG！ FB） - >（GE FA）= bはFALSE、それ以外の場合は！
(NL f a) (NL f b) --> (NL f a), a=b (NL f a) (NG f b) --> (NL f a), a=b
、= B（A F NL）> - 、= bの（NGのF b）は（A F NL）（A F NL）> - （NL F b）は（A F NL）
(NG f a) (NG f b) --> (NG f a), a=b
、= B（A F NG）> - （NGのF b）は（A F NG）
Named and auxiliary predicates can serve two purposes:
名前付き補助述語は、2つの目的を果たすことができます。
(a) making complex predicates easier to write and understand, and
（a）に書き、理解しやすいが、複雑な述語を作成し、
(b) providing a possible basis for naming and registering feature sets.
（b）の命名と機能セットを登録するための可能な基礎を提供します。
A named predicate definition has the following form:
名前の述語の定義は次の形式があります。
named-pred = "(" fname *pname ")" ":-" filter fname = ftag ; Feature predicate name pname = token ; Formal parameter name
名前の-predは= "（" FNAMEの*のPNAME "）" "： - " フィルタFNAME = FTAG。フィーチャー述語名PNAME =トークン。正式なパラメータ名
'fname' is the name of the predicate.
「fnameが」述語の名前です。
'pname' is the name of a formal parameter which may appear in the predicate body, and which is replaced by some supplied value when the predicate is invoked.
「pnameが」述語本体に表示されることがあり、述語が呼び出されたときに、いくつかの指定された値に置き換えた仮パラメータの名前です。
'filter' is the predicate body. It may contain references to the formal parameters, and may also contain references to feature tags and other values defined in the environment in which the predicate is invoked. References to formal parameters may appear anywhere where a reference to a feature tag ('ftag') is permitted by the syntax for ' filter'.
「フィルタ」は述語体です。これは、仮パラメータへの参照を含むことができ、また、述語が起動されている環境で定義されたタグと他の値を搭載したリファレンスが含まれていてもよいです。特徴タグ（「FTAG」）への参照は、「フィルタ」の構文によって許可される仮パラメータへの参照は、どこにでも現れることができます。
The only specific mechanism defined by this memo for introducing a named predicate into a feature set definition is the "auxiliary predicate" described later. Specific negotiating protocols or other specifications may define other mechanisms.
機能セット定義に名前述語を導入するため、このメモで定義された唯一の具体的な機構は、後述の「補助述語」です。特定の交渉プロトコルまたは他の仕様は、他のメカニズムを定義してもよいです。
NOTE: There has been some suggestion of creating a registry for feature sets as well as individual feature values. Such a registry might be used to introduce named predicates corresponding to these feature sets into the environment of a capability assertion. Further discussion of this idea is beyond the scope of this memo.
注：機能セットだけでなく、個々の特徴値のレジストリを作成するためのいくつかの提案がなされてきました。このようなレジストリは、能力アサーションの環境にこれらの機能セットに対応した名前の述語を導入するために使用される可能性があります。このアイデアのさらなる議論はこのメモの範囲を超えています。
Assuming a named predicate has been introduced into the environment of some other predicate, it can be invoked by a filter 'ext-pred' of the form:
名前の述語がいくつかの他の述語の環境に導入されたと仮定すると、それはフィルタ「EXT-predは」形式のことで呼び出すことができます。
ext-pred = fname *param param = expr
EXT-フロントFNAME = PARAM * PARAM = exprの
The number of parameters must match the definition of the named predicate that is invoked.
パラメータの数が呼び出されるという名前の述語の定義と一致する必要があります。
A auxiliary predicate is attached to a filter definition by the following extension to the "filter" syntax:
補助述語は、「フィルタ」構文を次のように拡張することにより、フィルタ定義に取り付けられています。
filter =/ "(" filtercomp *( ";" parameter ) ")" "where" 1*( named-pred ) "end"
フィルタ= / "（" filtercomp×（ ";" パラメータ） "）" "" 1 *（名前付きPRED） "終了"
The named predicates introduced by "named-pred" are visible from the body of the "filtercomp" of the filter to which they are attached, but are not visible from each other. They all have access to the same environment as "filter", plus their own formal parameters. (Normal scoping rules apply: a formal parameter with the same name as a value in the environment of "filter" effectively hides the environment value from the body of the predicate to which it applies.)
「名前-predが」によって導入された名前の述語は、それらが結合しているフィルタの「filtercomp」の身体から可視であるが、互いから見えません。彼らは皆、「フィルタ」、プラス自分の仮パラメータと同じ環境へのアクセス権を持っています。 （通常のスコープ規則が適用されます：「フィルタ」の環境での値と同じ名前の仮パラメータには、効果的にそれが適用される述語の身体から環境値を非表示になります。）
NOTE: Recursive predicates are not permitted. The scoping rules should ensure this.
注：再帰述語は許可されていません。スコープ規則はこのことを確認する必要があります。
The preceding procedures can be extended to deal with named predicates simply by instantiating (i.e. substituting) the predicates wherever they are invoked, before performing the conversion to disjunctive normal form. In the absence of recursive predicates, this procedure is guaranteed to terminate.
前述の手順は、単にそれらは選言標準形への変換を実行する前に、呼び出される限り（すなわち、置換）述語をインスタンス化することによって命名さ述語を扱うように拡張することができます。再帰述語がない場合には、この手順は終了することが保証されます。
When substituting the body of a precdicate at its point of invocation, instances of formal parameters within the predicate body must be replaced by the corresponding actual parameter from the point of invocation.
呼び出しのその時点でprecdicateの本体を置換するとき、述語本体内の仮パラメータのインスタンスは、呼び出しの点から対応する実パラメータによって置き換えられなければなりません。
This example restates that given in section 4.3 using an auxiliary predicate named 'Res':
この例では、「RES」という名前の補助述語を使用してセクション4.3で与えられたことを修正再表示します：
(| (& (Pix-x=1024) (Pix-y=768) (Res Res-x Res-y) ) (& (Pix-x=800) (Pix-y=600) (Res Res-x Res-y) );q=0.9 (& (Pix-x=640) (Pix-y=480) (Res Res-x Res-y) );q=0.8 ) where (Res Res-x Res-y) :- (| (& (Res-x=150) (Res-y=150) ) (& (Res-x=150) (Res-y=300) ) (& (Res-x=300) (Res-y=300) ) (& (Res-x=300) (Res-y=600) ) (& (Res-x=600) (Res-y=600) ) ) end
（|（＆（PIX-X = 1024）（PIX-Y = 768）（RES RES-X RES-Y）（＆（PIX-X = 800）（PIX-Y = 600））（RES RES-X RES -y））; Q = 0.9（＆（PIX-X = 640））（PIX-Y = 480（RESのRESのRES-X-Y））; Q = 0.8）（RESのRESのRES-X-Y）： - （|（＆（RES-X = 150）（RES-Y = 150））（＆（RES-X = 150）（RES-Y = 300））（＆（RES-X = 300）（RES-Y = 300））（＆（RES-X = 300）（RES-Y = 600））（＆（RES-X = 600）（RES-Y = 600）））終了
Note that the formal parameters of "Res", "Res-x" and "Res-y", prevent the body of the named predicate from referencing similarly-named feature values.
「RES」の仮パラメータ、「RES-X」および「RES-Y」は、同様の名前の特徴量を参照するから名前述語の本体を防ぐことに留意されたいです。
In some exceptional cases, there may be differing conventions for the units of measurement of a given feature. For example, resolution is commonly expressed as dots per inch (dpi) or dots per centimetre (dpcm) in different applications (e.g. printing vs faxing).
いくつかの例外的なケースでは、与えられた特徴の測定単位のための異なる規則があってもよいです。例えば、解像度は、通常、異なるアプリケーション（ファックスVS例えば印刷）でインチあたりのドット数（DPI）またはセンチメートルあたりのドット数（DPCM）として表現されます。
In such cases, a unit designator may be appended to a feature value according to the conventions indicated below (see also [3]). These considerations apply only to features with numeric values.
このような場合には、単位指定子は、以下に示す規則に従って特徴量に付加することができる（参照[3]）。これらの考慮事項は、数値だけで機能に適用されます。
Every feature tag has a standard unit of measurement. Any expression of a feature value that uses this unit is given without a unit designation -- this is the normal case. When the feature value is expressed in some other unit, a unit designator is appended to the numeric feature value.
すべての機能タグは、測定の標準単位を持っています。このユニットを使用する特徴量のいずれかの発現は、単位指定せずに与えられる - これは通常の場合です。特徴量は、いくつかの他の単位で表現される場合、単位指定子は、数値特徴量に付加されます。
The registration of a feature tag indicates the standard unit of measurement for a feature, and also any alternate units and corresponding unit designators that may be used, according to RFC 2506 [3].
特徴タグの登録は、機能の測定の標準単位を表し、また、任意の代替ユニットおよびRFC 2506に従って使用され得る対応する単位指定子、[3]。
Thus, if the standard unit of measure for resolution is 'dpcm', then the feature predicate '(res=200)' would be used to indicate a resolution of 200 dots-per-centimetre, and '(res=72dpi)' might be used to indicate 72 dots-per-inch.
したがって解像度の尺度の標準単位は「DPCM」である場合、次に特徴述語「（RES = 200）」200のドット・パー・センチメートルの解像度を示すために使用されるであろう、そして「（RES = 72dpiです）」かもしれません72インチ当たりのドット数を示すために使用されます。
Unit designators are accommodated by the following extension to the feature predicate syntax:
単位指定子は、機能の述語構文に以下の拡張によって収容されています。
fvalue =/ number *WSP token
fvalue = /数* WSPトークン
When performing feature set matching, feature comparisons with and without unit designators, or feature comparisons with different unit designators, are treated as if they were different features. Thus, the feature predicate '(res=200)' would not, in general, fail to match with the predicate '(res=200dpi)'.
特徴セットマッチング、異なる単位指定子を有するユニット指定子、または特徴の比較とない特徴の比較を行う場合、それらは異なる機能しているかのように扱われます。したがって、特徴述語「（RES = 200）」、一般的に、「（RES = 200dpiの）」述部に一致するように失敗しないであろう。
NOTE: A protocol processor with specific knowledge of the feature and units concerned might recognize the relationship between the feature predicates in the above example, and fail to match these predicates.
注：機能と、上記の例における特徴述語の関係を認識し、これらの述部に一致するように失敗することがあり、当該ユニットの特定の知識を持つプロトコルプロセッサ。
This appears to be a natural behaviour in this simple example, but can cause additional complexity in more general cases. Accordingly, this is not considered to be required or normal behaviour. It is presumed that an application concerned will ensure consistent feature processing by adopting a consistent unit for any given feature.
これは、この単純な例では自然な行動であるように思われるが、より一般的なケースでは、追加の複雑さを引き起こす可能性があります。したがって、これを必要としていると考えたり、通常の動作ではありません。当該アプリケーションは、任意の機能のための一貫性のある手段を採用することにより、一貫した機能処理を確実にすると考えられます。
This memo has dealt with feature values that have well-understood comparison properties: numbers, with equality, less-than, greater-than relationships, and other values with equality relationships only.
、小なり、平等で、数字より大平等の関係のみとの関係、およびその他の値：このメモは、比較の特性をよく理解している特徴値を扱っています。
Some feature values may have comparison operations that are not covered by this framework. For example, strings containing multi-part version numbers: "x.y.z". Such feature comparisons are not covered by this memo.
いくつかの特徴値は、このフレームワークでカバーされていない比較演算を有することができます。マルチパートのバージョン番号を含むたとえば、文字列：「X.Y.Z」。このような特徴の比較はこのメモでカバーされていません。
Specific applications may recognize and process feature tags that are associated with such values. Future work may define ways to introduce new feature value data types in a way that allows them to be used by applications that do not contain built-in knowledge of their properties.
特定のアプリケーションは、そのような値に関連付けられているタグを認識し、処理機能してもよいです。今後の作業は、彼らの性質の組み込みの知識が含まれていないアプリケーションで使用することを可能にする方法で、新しい機能値のデータ型を導入する方法を定義することができます。
This example considers sending a document to a high-end black-and-white fax system with the following receiver capabilities:
この例では、次の受信機能を備えたハイエンド白黒ファックスシステムに文書を送信考慮する。
(& (dpi=[200,300]) (grey=2) (color=0) (image-coding=[MH,MR]) )
（＆（DPI = [200,300]）（灰色= 2）（色= 0）（画像符号化= [MH、MR]））
Turning to the document itself, assume it is available to the sender in three possible formats, A4 high resolution, B4 low resolution and A4 high resolution colour, described by:
文書自体に目を向けると、それによって説明した3つの可能なフォーマット、A4高解像度、B4低解像度及びA4高解像度カラーで送信者に利用可能であると仮定する。
(& (dpi=300) (grey=2) (image-coding=MR) )
（＆（DPI = 300）（灰色= 2）（画像符号化= MR））
(& (dpi=200) (grey=2) (image-coding=[MH,MMR]) )
（＆（DPI = 200）（灰色= 2）（画像符号化= [MH、MMR]））
(& (dpi=300) (dpi-xyratio=1) (color<=256) (image-coding=JPEG) )
（＆（DPI = 300）（DPI-xyratio = 1）（色<= 256）（画像符号化= JPEG））
These three image formats can be combined into a composite capability statement by a logical-OR operation (to describe format-1 OR format-2 OR format-3):
これら3つの画像フォーマットは、（フォーマット1またはフォーマット2 ORフォーマット3を記述するために）論理OR演算により複合能力文に組み合わせることができます。
(| (& (dpi=300) (grey=2) (image-coding=MR) ) (& (dpi=200) (grey=2) (image-coding=[MH,MMR]) ) (& (dpi=300) (color<=256) (image-coding=JPEG) ) )
（|（＆（DPI = 300）（灰色= 2）（画像符号化= MR））（＆（DPI = 200）（灰色= 2）（画像符号化= [MH、MMR]））（＆（DPI = 300）（色<= 256）（画像符号化= JPEG）））
The composite document description can be matched with the receiver capability description by combining the capability descriptions with a logical AND operation:
複合文書記述は、論理AND演算と機能の説明を組み合わせることにより、受信機機能の説明と一致させることができます。
(& (& (dpi=[200,300]) (grey=2) (color=0) (image-coding=[MH,MR]) ) (| (& (dpi=300) (grey=2) (image-coding=MR) ) (& (dpi=200) (grey=2) (image-coding=[MH,MMR]) ) (& (dpi=300)
（＆（＆（DPI = [200,300]））2 =（灰色（色= 0）（画像符号化= [MH、MR]））（|）2 =（＆（DPI = 300）（灰色（イメージ - コーディング= MR））（＆（DPI = 200）（灰色= 2）（画像符号化= [MH、MMR]））（＆（DPI = 300）
(color<=256)
(image-coding=JPEG) ) ) )
--> Expand value-set notation:
- >値設定表記を展開します。
(& (& (| (dpi=200) (dpi=300) ) (grey=2) (color=0) (| (image-coding=MH) (image-coding=MR) ) ) (| (& (dpi=300) (grey=2) (image-coding=MR) ) (& (dpi=200) (grey=2) (| (image-coding=MH) (image-coding=MMR) ) ) (& (dpi=300) (color<=256) (image-coding=JPEG) ) ) )
（＆（＆（|（DPI = 200）（DPI = 300））（灰色= 2）（色= 0）（|（画像符号化= MH）（画像符号化= MR）））（|（＆（ DPI = 300）（2 =グレー）（画像符号化= MR））（＆（DPI = 200）（灰色= 2）（|（画像符号化= MH）（画像符号化= MMR）））（＆（ DPI = 300）（色<= 256）（画像符号化= JPEG））））
--> Flatten nested '(&...)':
- > '（＆...）' ネストされたフラット化：
(& (| (dpi=200) (dpi=300) ) (grey=2) (color=0) (| (image-coding=MH) (image-coding=MR) ) (| (& (dpi=300) (grey=2) (image-coding=MR) ) (& (dpi=200) (grey=2) (| (image-coding=MH) (image-coding=MMR) ) ) (& (dpi=300) (color<=256) (image-coding=JPEG) ) ) )
（＆（|（DPI = 200）（DPI = 300）））2 =（灰色（色= 0）（|（画像符号化= MH）（画像符号化= MR））（|（＆（DPI = 300 ）（灰色= 2）（画像符号化= MR））（＆（DPI = 200））2 =（灰色（|（画像符号化= MH）（画像符号化= MMR）））（＆（DPI = 300 ）（色<= 256）（画像符号化= JPEG））））
--> (distribute '(&...)' over inner '(|...)'):
- >（インナーの上に '）...＆（' 配布 '（| ...）'）：
(& (| (dpi=200) (dpi=300) ) (grey=2) (color=0) (| (image-coding=MH) (image-coding=MR) ) (| (& (dpi=300) (grey=2) (image-coding=MR) ) (& (dpi=200) (grey=2) (image-coding=MH) ) (& (dpi=200) (grey=2) (image-coding=MMR) ) (& (dpi=300) (color<=256) (image-coding=JPEG) ) ) )
（＆（|（DPI = 200）（DPI = 300）））2 =（灰色（色= 0）（|（画像符号化= MH）（画像符号化= MR））（|（＆（DPI = 300 ）（灰色= 2）（画像符号化= MR））（＆（DPI = 200）（灰色= 2）（画像符号化= MH））（＆（DPI = 200））2 =（グレー（画像符号化= MMR））（＆（DPI = 300）（色<= 256）（画像符号化= JPEG））））
--> continue to distribute '(&...)' over '(|...)', and flattening nested '(&...)' and '(|...)' ...:
- >オーバー '（| ...）' '（＆...）' 配布し続け、およびネストされた平坦化 '（＆...）' と '（| ...'）...：
(| (& (dpi=200) (grey=2) (color=0) (image-coding=MH) (| (& (dpi=300) (grey=2) (image-coding=MR) )
（|（＆（DPI = 200）（灰色= 2）（色= 0）（画像符号化= MH）（|（＆（DPI = 300）（灰色= 2）（画像符号化= MR））
(& (dpi=200) (grey=2) (image-coding=MH) ) (& (dpi=200) (grey=2) (image-coding=MMR) ) (& (dpi=300) (color<=256) (image-coding=JPEG) ) ) ) (& (dpi=200) (grey=2) (color=0) (image-coding=MR) (| (& (dpi=300) (grey=2) (image-coding=MR) ) (& (dpi=200) (grey=2) (image-coding=MH) ) (& (dpi=200) (grey=2) (image-coding=MMR) ) (& (dpi=300) (color<=256) (image-coding=JPEG) ) ) ) (& (dpi=300) (grey=2) (color=0) (image-coding=MH) (| (& (dpi=300) (grey=2) (image-coding=MR) ) (& (dpi=200) (grey=2) (image-coding=MH) ) (& (dpi=200) (grey=2) (image-coding=MMR) ) (& (dpi=300) (color<=256) (image-coding=JPEG) ) ) ) (& (dpi=300) (grey=2) (color=0) (image-coding=MR) (| (& (dpi=300) (grey=2) (image-coding=MR) ) (& (dpi=200) (grey=2) (image-coding=MH) ) (& (dpi=200) (grey=2) (image-coding=MMR) ) (& (dpi=300) (color<=256) (image-coding=JPEG) ) ) ) )
（＆（DPI = 200）（灰色= 2）（画像符号化= MH））（＆（DPI = 200）（灰色= 2）（画像符号化= MMR））（＆（DPI = 300）（色< = 256）（画像符号化= JPEG））））（＆（DPI = 200））2 =（灰色（色= 0）（画像符号化= MR）（|（＆（DPI = 300）（灰色= 2 ）（画像符号化= MR））（＆（DPI = 200）（灰色= 2）（画像符号化= MH））（＆（DPI = 200）（灰色= 2）（画像符号化= MMR））（ ＆（DPI = 300）（色<= 256）（画像符号化= JPEG））））（＆（DPI = 300））2 =（灰色（色= 0）（画像符号化= MH）（|（＆ （DPI = 300）（灰色= 2）（画像符号化= MR））（＆（DPI = 200）（灰色= 2）（画像符号化= MH））（＆（DPI = 200）（灰色= 2） （画像符号化= MMR））（＆（DPI = 300）（色<= 256）（画像符号化= JPEG））））（＆（DPI = 300）（灰色= 2）（色= 0）（画像-coding = MR）（|（＆（DPI = 300））2 =（グレー（画像符号化= MR））（＆（DPI = 200）（灰色= 2）（画像符号化= MH））（＆（ DPI = 200）（灰色= 2）（画像符号化= MMR））（＆（DPI = 300）（色<= 256）（画像符号化= JPEG）））））
--> ... until normal form is achieved:
- > ...正規形が達成されるまで：
(| (& (dpi=200) (grey=2) (color=0) (image-coding=MH) (dpi=300) (grey=2) (image-coding=MR) ) (& (dpi=200) (grey=2) (color=0) (image-coding=MR) (dpi=300) (grey=2) (image-coding=MR) ) (& (dpi=300) (grey=2) (color=0) (image-coding=MH) (dpi=300) (grey=2) (image-coding=MR) ) (& (dpi=300) (grey=2) (color=0) (image-coding=MR) (dpi=300) (grey=2) (image-coding=MR) ) (& (dpi=200) (grey=2) (color=0) (image-coding=MH) (dpi=200) (grey=2) (image-coding=MH) ) (& (dpi=200) (grey=2) (color=0) (image-coding=MR) (dpi=200) (grey=2) (image-coding=MH) ) (& (dpi=300) (grey=2) (color=0) (image-coding=MH) (dpi=200) (grey=2) (image-coding=MH) ) (& (dpi=300) (grey=2) (color=0) (image-coding=MR) (dpi=200) (grey=2) (image-coding=MH) ) (& (dpi=200) (grey=2) (color=0) (image-coding=MH) (dpi=200) (grey=2) (image-coding=MMR) ) (& (dpi=200) (grey=2) (color=0) (image-coding=MR) (dpi=200) (grey=2) (image-coding=MMR) ) (& (dpi=300) (grey=2) (color=0) (image-coding=MH) (dpi=200) (grey=2) (image-coding=MMR) ) (& (dpi=300) (grey=2) (color=0) (image-coding=MR) (dpi=200) (grey=2) (image-coding=MMR) ) (& (dpi=200) (grey=2) (color=0) (image-coding=MH) (dpi=300) (color<=256) (image-coding=JPEG) ) ) ) (& (dpi=200) (grey=2) (color=0) (image-coding=MR)
（|（＆（DPI = 200）（灰色= 2）（色= 0）（画像符号化= MH）（DPI = 300）（灰色= 2）（画像符号化= MR））（＆（DPI = 200 ）（灰色= 2）（色= 0）（画像符号化= MR）（DPI = 300）（灰色= 2）（画像符号化= MR））（＆（DPI = 300））2 =（灰色（色= 0）（画像符号化= MH）（DPI = 300））2 =（グレー（画像符号化= MR））（＆）2 =（DPI = 300）（灰色（色= 0）（画像符号化= MR）（DPI = 300）（灰色= 2）（画像符号化= MR））（＆（DPI = 200）（灰色= 2）（色= 0）（画像符号化= MH）（DPI = 200）（灰色= 2）（画像符号化= MH））（＆（DPI = 200））2 =（灰色（色= 0）（画像符号化= MR）（DPI = 200））2 =（グレー（画像符号化= MH））（＆）2 =（DPI = 300）（灰色（色= 0）（画像符号化= MH）（DPI = 200）（灰色= 2）（画像符号化= MH））（＆（DPI = 300）（灰色= 2）（色= 0）（画像符号化= MR）（DPI = 200）（2 =グレー）（画像符号化= MH））（＆（DPI = 200）（灰色= 2） （色= 0）（画像符号化= MH）（DPI = 200）（灰色= 2）（画像符号化= MMR））（＆（DPI = 200）（灰色= 2）（色= 0）（イメージ - コーディング= MR）（DPI = 200））2 =（グレー（画像符号化= MMR））（＆（DPI = 300））2 =（灰色（色= 0）（画像符号化= MH）（DPI = 200 ）（灰色= 2）（画像符号化= MMR））（＆（DPI = 300）（Gレイ= 2）（色= 0）（= MR）（DPI = 200）（灰色= 2）（画像符号化= MMR））（＆（DPI = 200）（灰色= 2）（カラー画像符号化= 0 ）（画像符号化= MH）（DPI = 300）（色<= 256）（画像符号化= JPEG））））（＆（DPI = 200））2 =（灰色（色= 0）（画像符号化= MR）
(dpi=300) (color<=256) (image-coding=JPEG) ) ) ) (& (dpi=300) (grey=2) (color=0) (image-coding=MH) (dpi=300) (color<=256) (image-coding=JPEG) ) ) ) (& (dpi=300) (grey=2) (color=0) (image-coding=MR) (dpi=300) (color<=256) (image-coding=JPEG) ) )
（DPI = 300）（色<= 256）（画像符号化= JPEG））））（＆（DPI = 300）（灰色= 2）（色= 0）（画像符号化= MH）= 300（DPI） （色<= 256）（画像符号化= JPEG））））（＆（DPI = 300）（灰色= 2）（色= 0）（画像符号化= MR）（DPI = 300）（色<= 256 ）（画像符号化= JPEG）））
--> Group terms in each conjunction by feature tag:
- >フィーチャータグにより、それぞれ連携してグループの用語：
(| (& (dpi=200) (dpi=300) (grey=2) (grey=2) (color=0) (image-coding=MH) (image-coding=MR) ) (& (dpi=200) (dpi=300) (grey=2) (grey=2) (color=0) (image-coding=MR) (image-coding=MR) ) : (etc.) : (& (dpi=300) (dpi=300) (grey=2) (color=0) (color<=256) (image-coding=MR) (image-coding=JPEG) ) )
（|（＆（DPI = 200）（DPI = 300）（灰色= 2）（灰色= 2）（色= 0）（画像符号化= MH）（画像符号化= MR））（＆（DPI = 200 ）（DPI = 300）（灰色= 2）（灰色= 2）（色= 0）（画像符号化= MR）（画像符号化= MR））：（等）：（＆（DPI = 300）（ DPI = 300）（灰色= 2）（色= 0）（色<= 256）（画像符号化= MR）（画像符号化= JPEG）））
--> Combine feature tag comparisons and eliminate unsatisfiable conjunctions:
- >フィーチャータグ比較を組み合わせると充足不能接続詞を排除：
(| (& (dpi=300) (grey=2) (color=0) (image-coding=MR) ) (& (dpi=200) (grey=2) (color=0) (image-coding=MH) ) )
（|（＆（DPI = 300）（灰色= 2）（色= 0）（画像符号化= MR））（＆（DPI = 200）（灰色= 2）（色= 0）（MH =画像符号化）））
Thus, we see that this combination of sender and receiver options can transfer a bi-level image, either at 300dpi using MR coding, or at 200dpi using MH coding.
したがって、我々は、送信者と受信者のオプションのこの組合せは、MH符号化を使用して、または200dpiのにMR符号化を使用してのいずれかでは300dpiで、2値画像を転送することができることがわかります。
Points to note about the feature matching process:
特徴マッチングプロセスについての注意点：
o The colour document option is eliminated because the receiver cannot handle either colour (indicated by '(color=0)') or JPEG coding.
Oカラー文書オプションは、受信機が処理のいずれか又はJPEG符号（「（色= 0）」で示される）色ことができないので排除されます。
o The high resolution version of the document with '(dpi=300)' must be sent using '(image-coding=MR)' because this is the only available coding of the image data that the receiver can use for high resolution documents. (The available 300dpi document codings here are MMR and MH, and the receiver capabilities are MH and MR.)
O「（DPI = 300）」と原稿の高解像度バージョンを使用して送信されなければならない「（=画像符号化MR）」これは、受信機は、高解像度のドキュメントに使用できる画像データの符号化にのみ使用可能であるためです。 （ここでは利用可能300dpiの文書のコーディングは、MMRとMHであり、受信機の機能は、MHとMRです。）
This section contains some additional commentary on the interpretation of feture set predicates. It does not extend or modify what has been described previously. Rather, it attempts to clarify an area of possible misunderstanding.
このセクションでは、feture集合述語の解釈にいくつかの追加の解説が含まれています。これは、拡張したり、以前に記載されているものを変更しません。むしろ、それは誤解を招く可能性の範囲を明確化しようとします。
The essential fact that needs to be established here is:
ここで確立する必要不可欠な事実です。
Within a given feature collection, each feature tag may have only one value.
与えられた特徴のコレクションの中で、それぞれの特徴タグは一つの値だけを持つことができます。
This idea is explained below in the context of using the media feature framework to describe the characteristics of transmitted image data.
このアイデアは、送信された画像データの特性を記述するためにメディア機能フレームワークを使用してのコンテキストで説明します。
In this context, we have the requirement that any feature tag value must apply to the entire image, and cannot have different values for different parts of an image. This is a consequence of the way that the framework of feature predicates is used to describe different possible images, such as the different images that can be rendered by a given recipient.
この文脈において、我々は、任意の特徴タグ値を画像全体に適用しなければならない要件を有し、画像の異なる部分に異なる値を持つことができません。これは、特徴述のフレームワークは、所与の受信者によってレンダリングすることができる異なる画像として異なる可能な画像を記述するために使用される方法の結果です。
This idea is illustrated here using an example of a flawed feature set description based on the TIFF image format defined for use by Internet fax [13]:
このアイデアは、インターネットFAXで使用するために定義されたTIFF画像フォーマットに基づいて、欠陥のある機能セットの記述の例を用いてここに例示されている[13]。
(& (& (MRC-mode=1) (stripe-size=256) ) (| (& (image-coding=JBIG-2-LEVEL) (stripe-size=128) ) (image-coding=[MH,MR,MMR]) ) )
（＆（＆（MRC-MODE = 1）（ストライプサイズ= 256））（|（＆（画像符号化= JBIG-2-LEVEL）（ストライプサイズ= 128））（画像符号化= [MH、 MR、MMR]）））
This example is revealing because the 'stripe-size' attribute is applied differently to different attributes on an MRC-formatted data: it can be applied to the MRC format as a whole, and it can be applied separately to a JBIG image that may appear as part of the MRC data.
「ストライプサイズ」属性は、MRCフォーマットのデータに異なる属性に異なって適用されるので、この例では明らかにされている：それは全体としてMRCフォーマットに適用することができ、それが表示されることがJBIG画像に別々に適用することができますMRCデータの一部として。
One might imagine that this example describes a stripe size of 256 when applied to the MRC image format, and a separate stripe size of 128 when applied to a JBIG-2-LEVEL coded image within the MRC-formatted data. But it doesn't work that way: the predicates used obey the normal laws of Boolean logic, and would be transformed as follows:
一この例では、MRC画像フォーマットに適用される256のストライプサイズ、およびMRC-フォーマットされたデータ内JBIG-2値符号化された画像に適用される128の別個のストライプサイズを記述していることを想像するかもしれません。しかし、それはそのように動作しません：使用述語は、ブール論理の通常の法則に従うと、次のように変換されることになります。
--> [flatten nested (&...)]: (& (MRC-mode=1) (stripe-size=256) (| (& (image-coding=JBIG-2-LEVEL) (stripe-size=128) ) (image-coding=[MH,MR,MMR]) ) )
- > [ネストされた平坦化（＆...）]：（＆（MRC-MODE = 1）（ストライプサイズ= 256）（|（＆（= JBIG-2-LEVEL）（ストライプサイズの画像が符号化= 128））（画像符号化= [MH、MR、MMR]）））
--> [Distribute (&...) over (|...)]: (| (& (MRC-mode=1) (stripe-size=256) (& (image-coding=JBIG-2-LEVEL) (stripe-size=128) ) ) (& (MRC-mode=1) (stripe-size=[0..256]) (image-coding=[MH,MR,MMR]) ) )
- > [（...＆）配布オーバー（| ...）]：（|（＆（MRC-MODE = 1）（ストライプサイズ= 256）（＆（画像符号化= JBIG-2-LEVEL ）（ストライプサイズ= 128）））（＆（MRC-MODE = 1）（ストライプサイズ= [0 256]）（画像符号化= [MH、MR、MMR]）））
--> [Flatten nested (&...) and group feature tags]: (| (& (MRC-mode=1) (stripe-size=256) (stripe-size=128) (image-coding=JBIG-2-LEVEL) ) (& (MRC-mode=1) (stripe-size=256) (image-coding=[MH,MR,MMR]) ) )
- > [（...＆）ネストされた平坦化およびグループ特徴タグ]：（|（＆（MRC-MODE = 1）（ストライプサイズ= 256）（ストライプサイズ= 128）（画像符号化= JBIG- 2-LEVEL））（＆（MRC-MODE = 1）（ストライプサイズ= 256）（画像符号化= [MH、MR、MMR]）））
Examination of this final expression shows that it requires both ' stripe-size=128' and 'stripe-size=256' within the same conjunction. This is manifestly false, so the entire conjunction must be false, reducing the entire predicate expression to:
この最終的な発現の検査は、それが同一の組み合わせ内で「ストライプ・サイズ= 128」と「ストライプサイズ= 256」の両方が必要であることを示しています。これは明らかに偽であるので、全体の組み合わせは、全体に述語式を減らし、偽でなければなりません。
(& (MRC-mode=1)
(stripe-size=256)
(image-coding=[MH,MR,MMR]) ) )
This indicates that no MRC formatted data containing a JBIG-2-LEVEL coded image is permitted within the feature set, which is not what was intended in this case.
これは、JBIG-2-LEVEL符号化された画像を含むいかなるMRCフォーマットされたデータは、この場合、意図されたされていないどのような機能セット内に許可されていないことを示しています。
The only way to avoid this in situations when a given characteristic has different constraints in different parts of a resource is to use separate feature tags. In this example, 'MRC-stripe-size' and ' JBIG-stripe-size' could be used to capture the intent:
与えられた特性は、リソースのさまざまな部分で異なる制約を持っているときの状況でこれを回避する唯一の方法は、個別の機能タグを使用することです。この例では、「MRC-ストライプサイズ」と「JBIG-ストライプサイズは、」意図をキャプチャするために使用することができます。
(& (& (MRC-mode=1) (MRC-stripe-size=256) ) (| (& (image-coding=JBIG-2-LEVEL) (JBIG-stripe-size=128) ) (image-coding=[MH,MR,MMR]) ) )
（＆（＆（MRC-MODE = 1）（MRC-ストライプサイズ= 256））（|（＆（画像符号化= JBIG-2-LEVEL）（JBIGストライプサイズ= 128））（画像符号化= [MH、MR、MMR]）））
which would reduce to:
これに減少するであろう：
(| (& (MRC-mode=1)
(MRC-stripe-size=256)
(JBIG-stripe-size=128)
(image-coding=JBIG-2-LEVEL) )
(& (MRC-mode=1)
(MRC-stripe-size=256)
(image-coding=[MH,MR,MMR]) ) )
The property of the capability description framework explicated above is captured by the idea of a "feature collection" which (in this context) describes the feature values that apply to a single resource. Within a feature collection, each feature tag may have no more than one value.
上記explicated能力記述フレームワークのプロパティは、単一のリソースに適用される特徴値を記述する（この文脈における）「特徴コレクション」の考え方によって捕捉されます。機能のコレクションの中で、それぞれの特徴タグはありません以上1未満の値を有することができます。
The characteristics of an image sender or receiver are described by a "Feature set", which is formally a set of feature collections. Here, the feature set predicate is applied to some image feature collection to determine whether or not it belongs to the set that can be handled by an image receiver.
画像送信者または受信機の特性は、正式に特徴集合の集合である「機能セット」に記載されています。ここで、特徴セット述部は、画像受信部によって処理することができるセットに属するか否かを決定するために、いくつかの画像特徴のコレクションに適用されます。
Some security considerations for content negotiation are raised in [1,2,3].
コンテンツネゴシエーションのためのいくつかのセキュリティ上の考慮事項は、[1,2,3]で育っています。
The following are primary security concerns for capability identification mechanisms:
以下の機能識別メカニズムの主要なセキュリティ上の懸念のとおりです。
o Unintentional disclosure of private information through the announcement of capabilities or user preferences.
機能やユーザーの好みの発表による個人情報のO意図しない開示。
o Disruption to system operation caused by accidental or malicious provision of incorrect capability information.
間違った能力情報の偶然または悪意のある設けることによるシステム動作へのOの破壊。
o Use of a capability identification mechanism might be used to probe a network (e.g. by identifying specific hosts used, and exploiting their known weaknesses).
O機能識別メカニズムの使用は、（例えば、使用される特定のホストを識別し、それらの既知の弱点を利用することによって）ネットワークをプローブするために使用されるかもしれません。
The most contentious security concerns are raised by mechanisms which automatically send capability identification data in response to a query from some unknown system. Use of directory services (based on LDAP [7], etc.) seem to be less problematic because proper authentication mechanisms are available.
最も論争セキュリティ上の懸念は、自動的にいくつかの未知のシステムからの問い合わせに応答して機能識別データを送信するメカニズムによって提起されています。 （LDAP [7]などに基づいて）、ディレクトリサービスの使用は適切な認証メカニズムが利用可能であるため、問題が少ないように見えます。
Mechanisms that provide capability information when sending a message are less contentious, presumably because some intention can be inferred that person whose details are disclosed wishes to communicate with the recipient of those details. This does not, however, solve problems of spoofed supply of incorrect capability information.
メッセージを送信するときに能力情報を提供するメカニズムは、いくつかの意図が、その詳細は開示されている人が、これらの詳細の受信者と通信することを望んでいることを推測することができるので、おそらく、あまり論争です。これは、しかし、間違った能力情報の偽装された供給の問題を解決していません。
The use of format converting gateways may prove problematic because such systems would tend to defeat any message integrity and authenticity checking mechanisms that are employed.
そのようなシステムが採用されているメカニズムを確認するすべてのメッセージの完全性及び真正性を無効にする傾向があるので、フォーマット変換ゲートウェイの使用は問題を証明することができます。
Thanks are due to Larry Masinter for demonstrating the breadth of the media feature issue, and encouraging the development of some early thoughts.
おかげでメディア機能の問題の幅広さを実証し、いくつかの初期の思想の発展を奨励するためのラリーMasinterによるものです。
Many of the ideas presented derive from the "Transparent Content Negotiation in HTTP" work of Koen Holtman and Andy Mutz [4].
提示のアイデアの多くは、公園HoltmanとアンディMUTZ [4]の「透明なコンテンツネゴシエーションHTTPで」仕事から派生します。
Early discussions of ideas with the IETF HTTP and FAX working groups led to further useful inputs from Koen Holtman, Ted Hardie and Dan Wing. The debate later moved to the IETF 'conneg' working group, where Al Gilman and Koen Holtman were particularly helpful in refining the feature set algebra. Ideas for dealing with preferences and specific units were suggested by Larry Masinter.
IETF HTTPとFAXワーキンググループとアイデアの初期の議論は公園Holtman、テッドハーディーとダン・ウィングから、さらに便利な入力につながりました。議論は後にアルギルマンと公園Holtmanは代数を設定する機能を洗練する際に特に有用だったIETFのconneg "ワーキンググループに移動しました。好みや特定のユニットに対処するためのアイデアは、ラリーMasinterによって提案されました。
This work was supported by Content Technologies Ltd and 5th Generation Messaging Ltd.
この作品は、コンテンツテクノロジ株式会社および第5世代メッセージング株式会社によってサポートされていました
[1] Hardie, T., "Scenarios for the Delivery of Negotiated Content", Work in Progress.
[1]ハーディ、T.、「交渉コンテンツの配信のためのシナリオ」が進行中で働いています。
[2] Klyne, G., "Requirements for protocol-independent content negotiation", Work in Progress.
[2] Klyne、G.、 "プロトコルに依存しないコンテンツネゴシエーションのための要件"、ProgressのWork。
[3] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.
[3] Holtman、K.、MUTZ、A.、およびT.ハーディ、 "メディア特徴タグの登録手順"、BCP 31、RFC 2506、1999年3月。
[4] Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998.
[4] Holtman、K.とA. MUTZ、 "HTTPにおける透明コンテントネゴシエーション"、RFC 2295、1998年3月。
[5] "Programming in Prolog" (2nd edition), W. F. Clocksin and C. S. Mellish, Springer Verlag, ISBN 3-540-15011-0 / 0-387-15011-0, 1984.
[5] "Prologでプログラミング"（第2版）、W. F. Clocksin及びC. S.メリッシュ、シュプリンガーフェアラーク、ISBN 3-540-15011-0 / 0-387-15011-0、1984。
[6] Masinter, L., Holtman, K., Mutz, A., and D. Wing, "Media Features for Display, Print, and Fax", RFC 2534, March 1999.
[6] Masinter、L.、Holtman、K.、MUTZ、A.、およびD.翼、 "表示、印刷用メディアの機能、およびファックス"、RFC 2534、1999年3月。
[7] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[7]ワール、M.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）"、RFC 2251、1997年12月。
[8] Howes, T., "The String Representation of LDAP Search Filters", RFC 2254, December 1997.
[8]ハウズ、T.、 "LDAP検索フィルタの文字列表現"、RFC 2254、1997年12月に。
[9] Fielding, R., Gettys, J., Mogul, J., Frytyk, H. and T. Berners-Lee, "Hyptertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[9]フィールディング、R.、ゲティス、J.、モーグル、J.、Frytyk、H.、およびT.バーナーズ - リー、 "Hyptertext転送プロトコル - HTTP / 1.1"、RFC 2068、1997年1月。
[10] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
、RFC 2234、1997年11月： "ABNF構文仕様のための増大しているBNF" [10]クロッカー、D.、エディタ、およびP. Overell、。
[11] "Logic, Algebra and Databases", Peter Gray, Ellis Horwood Series: Computers and their Applications, ISBN 0-85312-709-3/0- 85312-803-3 (Ellis Horwood Ltd), ISBN 0-470-20103-7/0-470- 20259-9 (Halstead Press), 1984.
[11] "論理、代数とデータベース"、ピーター・グレイ、エリスホーウッドシリーズ：コンピュータとその応用、ISBN 0-85312-709-3 / 0- 85312-803-3（エリスホーウッド社）、ISBN 0-470- 20103から7 / 0-470- 20259から9（ハルステッドプレス）、1984。
[12] "Logic and its Applications", Edmund Burk and Eric Foxley, Prentice Hall, Series in computer science, ISBN 0-13-030263-5, 1996.
[12] "論理とその応用"、エドマンド・バークとEric Foxley、プレンティスホール、コンピュータサイエンスのシリーズ、ISBN 0-13-030263-5、1996。
[13] McIntyre, L., Buckley, R., Venable, D., Zilles, S., Parsons, G. and J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998.
[13]マッキンタイア、L.、バックリー、R.、VENABLE、D.、Zilles、S.、パーソンズ、G.とJ.・ラファティ、 "インターネットファックスのためのファイル形式"、RFC 2301、1998年3月。
[14] Apache content negotiation algorithm, <http://www.apache.org/docs/content-negotiation.html>
[14] Apacheのコンテンツネゴシエーションアルゴリズム、<http://www.apache.org/docs/content-negotiation.html>
Graham Klyne Content Technologies Ltd. 5th Generation Messaging Ltd. Forum 1 5 Watlington Street Station Road Nettlebed Theale Henley-on-Thames Reading, RG7 4RA RG9 5AB United Kingdom United Kingdom.
グラハムKlyneコンテンツテクノロジ株式会社第5世代メッセージング株式会社フォーラム1 5ワトリントンストリート駅道路Nettlebed Thealeヘンリーオンテムズ読書、RG7 4RA RG9 5ABイギリスイギリス。
Phone: +44 118 930 1300 +44 1491 641 641 Facsimile: +44 118 930 1301 +44 1491 641 611 EMail: GK@ACM.ORG
電話：+44 118 930 1300 +44 1491 641 641ファクシミリ：+44 118 930 1301 +44 1491 641 611 Eメール：GK@ACM.ORG
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。