[要約] RFC 2533は、メディア機能セットを記述するための構文を提供するものであり、その目的は、異なるメディア機能の相互運用性を向上させることです。
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.
Copyright（c）The Internet Society（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検索フィルターに基づく構文を記述する方法を大まかにモデル化しています。
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には、機能セットの一致の実用的な例が含まれており、このフレームワークを粘り気のある送信に適用することから生じる問題に拍車がかかった追加の説明コメントが含まれています。
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.
キーワード「必須」、「必要」、「必須」、「必要」、「しなければ」、「そうしない」、「ははは」、「ははは」、「推奨」、「5月」、「オプション」は、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
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.
機能セットは、ブール結果を返す任意の機能収集値の関数を述べています。真の結果は、対応する機能コレクションが、この述語によって定義されたメディア機能処理機能のセットに属していることを意味します。
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.
単一のメディア機能値は、リソースのインスタンス（印刷されたドキュメント、表示された画像など）を説明する機能コレクションの1つのコンポーネントと考えることができます。このような機能コレクションは、多くのメディア機能タグ（それぞれ[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である場合に真のブール値を返すブール関数（「述語」）。
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.
このような制約のシリーズを適用した結果、いくつかのメディア処理機能を表す機能コレクションのセットが小さくなります。個々の制約が、それぞれがいくつかのメディア処理機能を説明する述語によって表される場合、これらの制約の複合効果は、個々の制約の述語である述語によって表すことができる個々の制約機能の一部のサブセットです。
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）15色を使用した750x500ピクセル画像として、または（b）A4ページの150dpiでの750x500ピクセル画像として表示できるデータリソースについて説明しています。
(| (& (pix-x=750) (pix-y=500) (color=15) )
(& (dpi>=150) (papersize=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.
次の式では、（a）640*480ピクセルと1600万色（ピクセルあたり24ビット）、800*600ピクセル、64,000色（ピクセルあたり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:
次の例では、上記の最初の例で説明されているリソースが2番目の例で説明されている受信者に送信されたときに利用可能なドキュメント表現の範囲を説明します。これは、機能機能セットを組み合わせた結果です。
(| (& (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.
この式で説明されている機能セットは、前の2つの機能式で説明されているセットの交差点です。
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.
述語を表す方法はたくさんあります。このメモのアイデアは、プログラミング言語プロログ[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) )
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 'と「Papersize」は機能タグであり、「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 ディレクトリの選択は、属性値に対してサブストリング、おおよそ、および拡張可能な一致を提供します。このようなマッチングは、機能セットの選択には提供されません。
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 )
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.
注：ここで使用される品質値の構文は、http 'accept：' 'headers in rfc 2068 [9]、セクション3.9のヘッダーで定義されているものから撮影されました。ただし、ここで定義されている品質値の使用は、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 )
where: feature a1 is preferred over a2 feature b2 is preferred over b1
ここで：機能A1はA2よりも好まれますB1よりもB2が推奨されます
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) ).
この問題の提案されている解決策は、優先情報を組み合わせるための規則が提供されていないと単純に言うことです。上記の例に適用されると、（a2）または（b1）に関連する（a1）に関する（a1）に関する優先情報は、（＆（a1）（b1）（b1））関連に関する情報を伝えるとは推定されていません。to（＆（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).
実際には、これにより、優先情報の適用がトップレベルの述語条項への適用を制限します。トップレベルの節は、許容機能セットを完全に定義します。論理と演算子によって組み合わされた条項は、トップレベルの条項にすることはできません（後で説明する機能セットの述語の標準形式を参照）。
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「LDAP検索フィルターの文字列表現」[8]に基づいており、機能セットの選択に関連していない要素（上記で説明）を除外し、機能セット選択に固有の要素を追加する（例：オプション。品質値を述語に関連付けるため）。
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>
(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」を含む」で飾られた、単純な機能比較（「アイテム」、以下を参照）または複合フィルター（ 'and'、 '、'、 'not'）として定義されます。）。
A composite filter is a logical combination of one or more 'filter' values:
複合フィルターは、1つ以上の「フィルター」値の論理的な組み合わせです。
(& 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）は、フィルター値「f1」、「f2」の論理と「fn」です。つまり、それらのフィルターで表されるすべての述語を満たす機能コレクションによって満たされます。
(| 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'、 'f2' up to 'fn'の論理またはfnです。つまり、それらのフィルターで表される述語の少なくとも1つを満たす機能コレクションによって満たされます。
(! 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:
機能の比較は、「アイテム」の構文生産の「シンプル」オプションによって定義されます。3つの基本的な形式があります。
(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 <= value）「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> = value）「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]。機能を説明するために使用される機能タグは、そのメモに記載されている手順を使用して登録する必要があります。メディア機能登録手順メモ[3]で説明されているように、未登録の機能タグは「URIツリー」に割り当てる必要があります。
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.)
ブール値は、「真」と「false」という2つの事前定義された値を持つ単なるトークンです。（上部または下部の文字は、任意の組み合わせで使用できます。）
A numeric value is either a decimal integer, optionally preceded by a "+" or "-" sign, or rational number.
数値は小数整数のいずれかで、オプションでは "" or " - " sign、または合理的な数字が先行します。
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」として表され、オプションでは「 "" or " - " signが先行します。「n」と「m」は署名されていない小数整数であり、「n/m」で表される値は「m」で分割されます。したがって、以下はすべて1.5の有効な表現です。
3/2 +15/10 600/400
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**)
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)
Examples:
例：
The expression: ( paper-size=[A4,B4] ) can be used to express a capability to print documents on either A4 or B4 sized paper.
式：（ Paper-Size = [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.
式：（ width = [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] )
セット構成は、列挙された値と範囲を単一の式で結合できるように設計されています。
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」、および「RES-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 )
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
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つのレベルの最大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).
注：述語表現の通常の正規形式は「節型」です。一般的な述語式を変換する手順は、[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.
述語の「節型形式」は、命題の「接続詞正常形式」に類似しており、分離（論理的or）の接続詞（論理的および）です。ここで使用される関連フォームは、セットマッチングを特徴とする方が適しており、「分離的な通常の形式」であり、これは接続詞（または）の論理的な分離（または）です。この形式では、機能セットマッチングの目的は、いくつかの機能コレクションによって分離の少なくとも1つが満たされることを示すことです。
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.
標準形式のこの考慮事項は本当に必要ですか？結局のところ、機能の述語は単なるブール式ですよね？まあ、いいえ：特徴述語は、特徴の述語構文の「アイテム」で表されるプリミティブ特徴値テスト（比較）を含むブール式式です。これらのテストがすべて独立して真または偽であると想定できる場合、それぞれが原子命題と見なされ、述語全体を（比較的単純な）命題計算の規則に従って処理することができます。
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:
以下で拡張された機能セットのマッチング全体の戦略は次のとおりです。
1. Formulate the feature set match hypothesis.
1. 特徴セットの一致仮説を定式化します。
2. Replace "set" expressions with equivalent comparisons.
2. 「セット」式を同等の比較に置き換えます。
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 各機能グループについて、さまざまな制約を最小フォームにマージします。このプロセスは、特徴値の許容範囲の式の減少をもたらすか、値の誤りを含む式を生成します。これは、機能値の組み合わせが制約を満たすことができないことを示しています（この場合、対応する接続詞は決して満たすことができません）。
7. If the remaining disjunction contains at least one satisfiable conjunction, then the constraints are shown to be satisfiable.
7. 残りの分離に少なくとも1つの満足できる接続詞が含まれている場合、制約は満足できることが示されます。
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つの機能セットの述語「（p x）」と「（q x）」、「x」はいくつかの機能コレクションであり、真実を確立したいまたは命題のそうでなければ：
EXISTS(x) : (P x) AND (Q x)
存在する（x）：（ p x）および（q x）
i.e. does there exist a feature collection 'x' that satisfies both predicates, 'P' and 'Q'?
つまり、述語「P」と「Q」の両方を満たす機能「X」が存在しますか？
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)
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
The first two rules are extended forms of De Morgan's law, and the third is elimination of double negatives.
最初の2つのルールは、デ・モーガンの法則の拡張形式であり、3番目は二重ネガの排除です。
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)
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.
これらのルールは、目標述語を評価できるロジックステートメントのコアボディを形成します。これらのステートメントが表現される形式は、効果的な述語マッチングアルゴリズムを実現するために重要です（つまり、有効な結果をループしない、または有効な結果を見つけられないもの）。これらのルールを策定する最初のステップは、原始的な述語のフレームワークを簡素化することです。
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:
機能セットの定義が構築される原始的な述語は、「=」、 '<='、 '> ='です。機能値のペアを考えると、それらの間の関係は正確に次の1つでなければなりません。
(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'.
（lt a b）： 'a'は「b」よりも少ない。（eq a b）： 'a'は「b」に等しくなります。（gt a b）： 'a'は「b」よりも大きい。（ne a b）： 'a'は「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）： 'a'は「b」以下です。（ge a b）： 'a'は「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) )
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) )
using the following transformation rules:
次の変換ルールを使用してください。
(! (a = b) ) --> (| (NL a b) (NG a b) )
(! (a <= b) ) --> (NL a b)
(! (a >= b) ) --> (NG a b)
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 ... 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）
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.
ここから、各接続詞 '（＆...）'は個別に処理されます。元の目標が満足できるようにするには、これらのうちの1つだけが満足できる必要があります。
(A textbook conversion to clausal form [5,11] uses slightly different rules to yield a "conjunctive normal form".)
（節型への教科書の変換[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
(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
(NL f a) (NL f b) --> (NL f a), a>=b
(NL f b), otherwise
(NL f a) (NG f b) --> FALSE, a>=b
(NG f a) (NG f b) --> (NG f a), a<=b
(NG f b), otherwise
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
(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
(NL f a) (NL f b) --> (NL f a), a=b
(NL f a) (NG f b) --> (NL f a), a=b
(NG f a) (NG f b) --> (NG f a), a=b
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
'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:
名前の述語が他のいくつかの述語の環境に導入されていると仮定すると、フォームのフィルター「extred」によって呼び出すことができます。
ext-pred = fname *param param = expr
extpred = 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"
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.)
「名前を付けられたプレッド」によって導入された名前の述語は、それらが取り付けられているフィルターの「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.
呼び出しの時点で末端の本体を置き換える場合、述語本体内の正式なパラメーターのインスタンスは、呼び出しポイントから対応する実際のパラメーターに置き換える必要があります。
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
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).
いくつかの例外的な場合、特定の機能の測定単位に対して異なる規則がある場合があります。たとえば、解像度は一般に、さまざまなアプリケーション（例：印刷対ファックス）で1インチあたりのドット（DPI）またはドットパーセント1センチメートル（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） 'がかもしれません。1インチあたり72ドットを示すために使用されます。
Unit designators are accommodated by the following extension to the feature predicate syntax:
ユニット指定子は、次の拡張機能に対応しています。
fvalue =/ number *WSP token
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]）（gray = 2）（color = 0）（image-coding = [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）（gray = 2）（image-coding = mr））
(& (dpi=200) (grey=2) (image-coding=[MH,MMR]) )
（＆（dpi = 200）（gray = 2）（image-coding = [mh、mmr]））
(& (dpi=300) (dpi-xyratio=1)
(color<=256)
(image-coding=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つの画像形式は、論理または操作（Format-1またはFormat-2またはFormat-3を記述するため）によって複合能力ステートメントに結合できます。
(| (& (dpi=300) (grey=2) (image-coding=MR) ) (& (dpi=200) (grey=2) (image-coding=[MH,MMR]) ) (& (dpi=300) (color<=256) (image-coding=JPEG) ) )
（|（＆（dpi = 300）（gray = 2）（image-coding = mr））（＆（dpi = 200）（gray = 2）（image-coding = [mh、mmr]））（＆（dpi）= 300）（color <= 256）（image-coding = jpeg）））
The composite document description can be matched with the receiver capability description by combining the capability descriptions with a logical AND operation:
複合ドキュメントの説明は、機能の説明と論理および操作と操作を組み合わせることにより、受信機の機能説明と一致させることができます。
(& (& (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]）（gray = 2）（color = 0）（image-coding = [mh、mr]）））（|（＆（dpi = 300）（gray = 2）（image-コーディング= MR））（＆（dpi = 200）（gray = 2）（image-coding = [mh、mmr]））（＆（dpi = 300）））
(color<=256)
(image-coding=JPEG) ) ) )
--> Expand value-set notation:
- > value-set表記を展開：
(& (& (| (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) ) ) )
--> Flatten nested '(&...)':
- > 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) ) ) )
--> (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) ) ) )
--> continue to distribute '(&...)' over '(|...)', and flattening nested '(&...)' and '(|...)' ...:
- > '（＆...）' over '（| ...）'を分配し続け、ネストされた '（＆...）'および '（| ...）' ...：
(| (& (dpi=200) (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=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) ) ) ) )
--> ... 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=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) ) )
--> 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) ) )
--> 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) ) )
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.
したがって、この送信者と受信機のオプションの組み合わせは、MRコーディングを使用して300DPIで、またはMHコーディングを使用して200DPIでバイレベルの画像を転送できることがわかります。
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 Color Documentオプションは、受信機がどちらの色（ '（color = 0）'）またはJPEGコーディングで示されているかを処理できないため、削除されます。
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.
このセクションには、胎児セットの述語の解釈に関するいくつかの追加の解説が含まれています。以前に説明されていることを拡張または変更しません。むしろ、誤解の可能性がある領域を明確にしようとします。
The essential fact that needs to be established here is:
ここで確立する必要がある重要な事実は、次のとおりです。
Within a given feature collection, each feature tag may have only one value.
特定の機能コレクション内で、各機能タグには1つの値のみがあります。
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]:
このアイデアは、インターネットファックスで使用するために定義されたTIFF画像形式に基づいた欠陥機能セットの例を使用して、ここで説明されています[13]：
(& (& (MRC-mode=1) (stripe-size=256) )
(| (& (image-coding=JBIG-2-LEVEL) (stripe-size=128) )
(image-coding=[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]) ) )
--> [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]) ) )
--> [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]) ) )
- > [Flatten Nested（＆...）およびGroup Feature Tags]：（|（＆（mrc-mode = 1）（stripe-size = 256）（stripe-size = 128）（image-coding = jbig-2レベル）））（＆（mrc-mode = 1）（stripe-size = 256）（image-coding = [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:
この最終的な式の検査は、同じ接続詞内で「Stripe-Size = 128」と「Stripe-Size = 256」の両方が必要であることを示しています。これは明らかに誤っているため、接続詞全体が虚偽である必要があり、述語式全体を以下に減らす必要があります。
(& (MRC-mode=1) (stripe-size=256) (image-coding=[MH,MR,MMR]) ) )
（＆（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レベルのコード化された画像を含む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-Stripe-Size」と「JBig-Stripe-Size」を使用して、意図をキャプチャできます。
(& (& (MRC-mode=1) (MRC-stripe-size=256) )
(| (& (image-coding=JBIG-2-LEVEL) (JBIG-stripe-size=128) )
(image-coding=[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]) ) )
（|（＆（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.
上記で説明した機能説明フレームワークのプロパティは、（この文脈で）単一のリソースに適用される機能値を説明する「機能コレクション」のアイデアによってキャプチャされます。機能コレクション内では、各機能タグには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.
メディア機能の問題の幅を示し、いくつかの初期の考えの開発を奨励してくれたLarry Masinterに感謝します。
Many of the ideas presented derive from the "Transparent Content Negotiation in HTTP" work of Koen Holtman and Andy Mutz [4].
提示されたアイデアの多くは、Koen HoltmanとAndy 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ワーキンググループとのアイデアの初期の議論により、Koen Holtman、Ted Hardie、Dan Wingからのさらに有用な入力が発生しました。議論は後にIETF 'Conneg'ワーキンググループに移りました。そこでは、Al GilmanとKoen Holtmanが特徴セット代数の改良に特に役立ちました。好みと特定のユニットを扱うためのアイデアは、Larry Masinterによって提案されました。
This work was supported by Content Technologies Ltd and 5th Generation Messaging Ltd.
この作業は、Content Technologies Ltdと第5世代Messaging Ltdによってサポートされていました。
[1] Hardie, T., "Scenarios for the Delivery of Negotiated Content", Work in Progress.
[1] Hardie、T。、「交渉されたコンテンツの配信のシナリオ」、進行中の作業。
[2] Klyne, G., "Requirements for protocol-independent content negotiation", Work in Progress.
[2] Klyne、G。、「プロトコルに依存しないコンテンツネゴシエーションの要件」、進行中の作業。
[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. Hardie、「メディア機能タグ登録手順」、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. Mellish、Springer Verlag、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. Wing、「ディスプレイ、印刷、ファックス用のメディア機能」、RFC 2534、1999年3月。
[7] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[7] Wahl、M.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol（V3）」、RFC 2251、1997年12月。
[8] Howes, T., "The String Representation of LDAP Search Filters", RFC 2254, December 1997.
[8] Howes、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] Fielding、R.、Gettys、J.、Mogul、J.、Frytyk、H。and T. Berners-Lee、「Hyptertext Transfer Protocol-HTTP/1.1」、RFC 2068、1997年1月。
[10] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[10] Crocker、D.、Editor、およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[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（エリス・ホルウッドLtd）、ISBN 0-470-20103-7-7-7/0-470- 20259-9（Halstead Press）、1984年。
[12] "Logic and its Applications", Edmund Burk and Eric Foxley, Prentice Hall, Series in computer science, ISBN 0-13-030263-5, 1996.
[12] 「Logic and Its Applications」、Edmund BurkとEric Foxley、Prentice Hall、Computer Scienceのシリーズ、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] McIntyre、L.、Buckley、R.、Venable、D.、Zilles、S.、Parsons、G。and J. Rafferty、「Internet Faxのファイル形式」、RFC 2301、1998年3月。
[14] Apache content negotiation algorithm,
<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.
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イギリス英国。
Phone: +44 118 930 1300 +44 1491 641 641
Facsimile: +44 118 930 1301 +44 1491 641 611
EMail: GK@ACM.ORG
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。