RFC2533 日本語訳
2533 A Syntax for Describing Media Feature Sets. G. Klyne. March 1999. (Format: TXT=79057 bytes) (Updated by RFC2738, RFC2938) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Klyne Request for Comments: 2533 Content Technologies/5GM Category: Standards Track March 1999
Klyneがコメントのために要求するワーキンググループG.をネットワークでつないでください: 2533年の満足している技術/5GMカテゴリ: 1999年の標準化過程行進
A Syntax for Describing Media Feature Sets
メディア機能について説明するための構文はセットします。
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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
1. 序論…3 1.1 このドキュメントの構造…3 1.2 用語とコンベンションを記録してください…4 1.3 このドキュメントの議論…4 2. 満足している特徴用語と定義…4 3. メディアは組み合わせと能力を特徴とします…5 3.1のメディア機能…5 3.2のメディアが収集とセットを特徴とします…5 3.3のメディアがセット記述を特徴とします…6 3.4のメディアが組み合わせシナリオを特徴とします…7
Klyne Standards Track [Page 1] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[1ページ]RFC2533は1999年3月にセットを特集します。
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
3.4.1 データリソースオプション…7 3.4 .2 受取人能力…7 3.4 .3 オプションを結合します…7 3.5 セット述部を特徴としてください…8 3.5 ディレクトリ検索フィルタとの.1比較…8 3.6 好みについて説明します…9 3.7 好みを結合します…10 4. セット表現を特徴としてください…11 4.1 述部の原文の表現…11 4.2 特徴述部構文の解釈…12 4.2 .1 構文をフィルターにかけてください…12 4.2 .2 比較を特徴としてください…13 4.2 .3 タグを特集してください…13 4.2 .4 値を特徴としてください…14 4.2 .4 .1論理演算子は14 4.2.4.2のNumeric値14の4.2.4.3のToken値15の4.2.4.4String値15の4.2に.5Notational利器を評価します…15 4.3 セット定義の例を特徴としてください…16 5. マッチングはセットを特集します…16 5.1 セットマッチング戦略を特徴としてください…18 5.2 目標述部を定式化します…19 5.3 決まり文句を取り替えてください…19 5.4 論理的な否定内部を動かしてください…20 5.5 比較と論理的な否定を取り替えてください…20 5.6 正準への変換は形成されます…21 特徴述部の5.7組分け…22 5.8 単独形体規制を合併してください…22 5.8 簡素化のための.1の規則が値を命令しました…23 5.8 .2 順不同の値を簡素化するために、統治します…23 6. 他の特徴と問題…24 6.1 命名されて補助の述部…24 6.1 .1 命名された述部を定義します…24 6.1 .2 呼び出しは述部を命名しました…25 6.1 .3 フィルタの補助の述部…25 6.1 .4 命名された述部でマッチングを特徴としてください…25 6.1 .5の例…26 6.2の名称…26 6.3 未知の特徴値のデータ型…27 7. 例と追加コメント…27 7.1は例を扱いました…27 7.2 特徴タグの見るのに関する注…31 8. セキュリティ問題…34 9. 承認…34 10. 参照…35 11. 作者のアドレス…36 完全な著作権宣言文…37
Klyne Standards Track [Page 2] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[2ページ]RFC2533は1999年3月にセットを特集します。
1. Introduction
1. 序論
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.
特徴セット構文は特徴取り扱い能力で規制を定義する「数学の関係」として特徴セット述部を使用する原則で組立しています。 これは、送付者、受信機、およびファイル形式能力について説明するのに同じフォームの特徴セット式を使用できるのを許容します。 これは関係型データベースが1セットの結果値、およびLDAP検索フィルタに基づいている構文について説明するのにブールexpresionsを使用する方法で緩く似せられました。
1.1 Structure of this document
1.1 このドキュメントの構造
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は特徴セットマッチングのためのアルゴリズムを説明します。
Klyne Standards Track [Page 3] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[3ページ]RFC2533は1999年3月にセットを特集します。
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トランスミッションに適用しながら起こる問題によって拍車をかけられたいくつかの追加説明しているコメントを含みます。
1.2 Document terminology and conventions
1.2 ドキュメント用語とコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
NOTE: Comments like this provide additional nonessential
information about the rationale behind this document. Such
information is not needed for building a conformant
implementation, but may help those who wish to understand the
design in greater depth.
以下に注意してください。 このようなコメントは原理の追加不要不急な情報をこのドキュメントの後ろに供給します。 そのような情報は、conformant実装を築き上げるのに必要ではありませんが、より大きい深さでデザインを理解したがっている人を助けるかもしれません。
1.3 Discussion of this document
1.3 このドキュメントの議論
Discussion of this document should take place on the content negotiation and media feature registration mailing list hosted by the Internet Mail Consortium (IMC):
このドキュメントの議論は満足している交渉のときに行われるべきです、そして、メディアはインターネットメールConsortium(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/
http://www.imc.org/ietf-medfree/
2. Content feature terminology and definitions
2. 満足している特徴用語と定義
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.
特徴Collectionは異なったメディア機能と関連値の収集です。 これは特定の受取人によるドキュメントかリソースの特定のインスタンスの特定のレンダリングについて説明すると見なされるかもしれません。
Feature Set
is a set of zero, one or more feature collections.
特徴Setはゼロ、1つ以上の特徴収集のセットです。
Klyne Standards Track [Page 4] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[4ページ]RFC2533は1999年3月にセットを特集します。
NOTE: this term is used slightly differently by earlier work on
Transparent Content Negotiation in HTTP [4].
以下に注意してください。 今期はHTTP[4]にTransparent Content Negotiationへの以前の作業でわずかに異なって使用されます。
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.
ブール結果を返す任意の特徴収集価値のセット述部A関数を特徴としてください。 対応する特徴収集が特徴取り扱い能力がこの述部で定義したメディアの何らかのセットに属すことを意味するためにTRUE結果を取ります。
Other terms used in this memo are defined in [2].
このメモで使用される他の用語は[2]で定義されます。
3. Media feature combinations and capabilities
3. メディアは組み合わせと能力を特徴とします。
3.1 Media features
3.1 メディア機能
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.
そして、これらの値にはすべて、平等('=')のために比べて、そうすることができて、数値の、そして、注文された列挙値を比較できる特性がある、 より少なさ、-、すばらしさ、-、関係('<='、'>=')。 これらの基本的な比較操作は、より包括的な能力式に原始のブロックとして使用されます。
3.2 Media feature collections and sets
3.2のメディアが収集とセットを特徴とします。
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つの成分としてただ一つのメディア機能が評価するいずれも考えることができます。 そのような特徴収集は多くのメディア特徴タグから成ります。(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).
特徴セットは多くの特徴収集を含むセットです。 したがって、特徴セットは多くの異なったデータリソースインスタンスについて説明できます。 これらはただ一つのデータリソース(例えば与えられたドキュメントを印刷するのに使用される異なった解決)の異なった処理、一般的な処理(例えば、与えられたディスプレイのときに表すことができる異なったイメージの範囲)にかけられた、多くの異なったデータ源、またはこれらの何らかの組み合わせに対応できます(以下の例を見てください)。
Klyne Standards Track [Page 5] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[5ページ]RFC2533は1999年3月にセットを特集します。
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.
したがって、1つの特徴セットの記述はデータリソースの能力かデータリソースを処理するか、または表す何らかの実体について説明できます。
3.3 Media feature set descriptions
3.3のメディアがセット記述を特徴とします。
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.
特徴セットについて説明することへの一般的方法はものが何か可能であるという仮定から始めることです。 すなわち、特徴セットはすべての可能なドキュメントインスタンス(特徴収集)を含んでいます。 次に、これからドキュメントインスタンスを次第に取り除く適用された規制がセットしました。 例えば、モノクロのプリンタに関しては、色を使用するすべてのドキュメントインスタンスを取り除くか、または何らかの最小の解決のときに表さなければならないドキュメントに関して、セットから、より少ない解決があるすべてのドキュメントインスタンスを取り除きます。 セットからドキュメントインスタンスを取り除くのに使用されるメカニズムは「関係」の数学の考えです。 特徴収集が許容できるドキュメントインスタンスについて説明するなら、すなわち、特徴収集パラメタを取って、ブール値にそれを返すブール関数(「述部」)はTRUEであるか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.
+----------:----------+
:
P(C) P(C)は本当の<と等しいです: ->P(C)は虚偽で等しいです: +----------:----------+ この箱はいくつかを表します。| : | 特徴収集(C)のセット| 含まれている: 除かれます。| それは抑制されます。| : | 述部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である述部で表すことができる個々の規制能力の何らかの部分集合です。
3.4 Media feature combination scenario
3.4のメディアが組み合わせシナリオを特徴とします。
This section develops some example scenarios, introducing the notation that is defined formally in section 4.
セクション4で正式に定義される記法を導入して、このセクションはいくつかの例のシナリオを開発します。
Klyne Standards Track [Page 6] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[6ページ]RFC2533は1999年3月にセットを特集します。
3.4.1 Data resource options
3.4.1 データリソースオプション
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) A4ページの150dpiで15の色、または(b)を使用する750×500画素のイメージとして。
(| (& (pix-x=750) (pix-y=500) (color=15) )
(& (dpi>=150) (papersize=iso-A4) ) )
(|、((写真-x=750)(写真-y=500)(色の=15)((dpi>=150)(papersize=iso-A4)))
3.4.2 Recipient capabilities
3.4.2 受取人能力
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万の色(1画素あたり24ビット)、800*600画素、および64 1,000を表示できるスクリーンは(1画素あたり16ビット)か1024*768画素と256の色(1画素あたり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) ) )
写真..写真..色..写真..写真..色..写真..写真..色..メディア..上映..dpi..メディア..文房具
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).
この式がプリンタの色か灰色のスケール能力に関して沈黙することに注意してください。 ここに提示された体系では、それはこの点であえて自由です(より現実的に、どんなそのような規制もこの受取人に発信しながら、バンドの外でだれによっても扱われます)。
3.4.3 Combined options
3.4.3 結合したオプション
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) ) )
(|、((写真-x=750)(写真-y=500)(色の=15)((dpi=300)(ua-メディア=文房具)(papersize=iso-A4)))
The feature set described by this expression is the intersection of the sets described by the previous two capability expressions.
この式によって説明された特徴セットは前の2つの能力式によって説明されたセットの交差点です。
Klyne Standards Track [Page 7] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[7ページ]RFC2533は1999年3月にセットを特集します。
3.5 Feature set predicates
3.5 特徴セット述部
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]に使用される形式は採用されました、能力識別の要件のための良いマッチであり、非常に簡単な分析しやすくて、処理しやすい構造を持っているので。
3.5.1 Comparison with directory search filters
3.5.1 ディレクトリ検索フィルタとの比較
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)(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.)
'papersizeトークン'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 ディレクトリ選択はサブストリング、属性値のための大体の、そして、広げることができるマッチングを提供します。 そのようなマッチングは特徴セット選択に提供されません。
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 ディレクトリ選択は値への尊敬なしで属性の存在に基づくかもしれません。 このドキュメントによって説明された意味フレームワークの中では、同様の効果を供給するのにブールに評価された特徴テストを使用できます。
Klyne Standards Track [Page 8] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[8ページ]RFC2533は1999年3月にセットを特集します。
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.
データ型に依存する広げることができる合わせていて合っている規則の考えは必ず特徴選択構文に影響するというわけではないこのメモで扱われなかった問題の一面です。 構文を圧迫するかもしれない局面は選択式の一部としての明白な合っている規則の仕様でしょう。
3.6 Describing preferences
3.6 好みについて説明すること。
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.
範囲0〜1の数値上質の値は、好みに従って特徴セットを格付けするのに断片的な最大3ケタと共に使用されます。 下側の値より高い値は好ましいです、そして、等しい値はあえて等しく好まれます。 これを超えて、使用される実数はここで定義されなかった意味を全く持っています。 適切な意味論がそのような操作が使用されている文脈のために定義されていないなら、上質の値に関する四則演算は予測できない結果を生みそうです。
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 )
(| ((写真-x=750)(写真-y=500)(色の=15)); q=0.8((dpi>=150)(papersize=iso-A4));q=0.7)
Klyne Standards Track [Page 9] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[9ページ]RFC2533は1999年3月にセットを特集します。
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のためにRFC2068[9](セクション3.9)で'受け入れてください'というヘッダーを定義しました。 しかしながら、ここで定義された上質の値の使用はRFC2068で定義されたそれほど同じくらい遠くに行きません。
3.7 Combining preferences
3.7 好みを結合すること。
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) ).
この問題の提案された解決は規則が全く好みの情報を結合しながら備えられないと単に言うことです。 と関連して上記の例に適用されています、(a2)と関連した(a1)のどんな好みの情報、または(b2)と関連した(b1)もあえて好みに関して情報を伝達されない、((a1)(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]です。 また、上質の値を広げる他の仕事はアパッチHTTPサーバ[14]の満足している交渉アルゴリズムです。
Klyne Standards Track [Page 10] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[10ページ]RFC2533は1999年3月にセットを特集します。
4. Feature set representation
4. 特徴セット表現
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.
以上のセクションは、述部が収集を特徴とするように適用されている状態で特徴セットを定義するためにフレームワークについて説明しました。 このセクションは特徴セット述部の具体的な表現を提示します。
4.1 Textual representation of predicates
4.1 述部の原文の表現
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).
1つの特徴セットのテキスト代理はRFC2254「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]:
特徴述部の書式は以下で「フィルタ」のための生産で定義されます、RFC2234[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
「("filtercomp")」という=*をフィルターにかけてください、(「」、;、パラメタ) パラメタ=「q」「=」qvalue / ext-paramがext-値のqvalue=と「等しい」 (「0インチ[「.」 0*3DIGIT)/、(「1インチ、[「. 」 0*3、(「0インチ) ext-param=アルファ*(アルファ/ケタ/「-」)ext-値は<パラメタ価値と等しいです、/項目と=“&" filterlistか=ではなく、名前付のパラメタ>filtercomp=と/か/に従って」」|「filterlistが「=」という1*フィルタの“!"フィルタfilterlist=品目=簡単であるか設定している/ext-predセット=attrと等しくない、「「setentry*、(「」 setentry) 「「setentry=は」 」 範囲の範囲=が評価する/を評価」」; 「「ftag等しいか、よりすばらしいかそれほど等しくない=値簡単な=attr filtertype値filtertype=「=」大=「>=」より少ない=「<=」attr=値=fvalue ftagは<特徴タグと等しいです、RFC2506 3>fvalue=論理演算子/数/トークン/ストリング論理演算子=の「本当」の、または、「誤った」番号=合理的な整数=整数/「+」/「-」1*ケタ合理的な=「+」/「-」1*ケタで定義されるように」/」1*ケタ
Klyne Standards Track [Page 11] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[11ページ]RFC2533は1999年3月にセットを特集します。
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>
トークン=アルファー*(アルファー/ DIGIT /「-」)ストリングはDQUOTE*(%x20-21/%x23-7E)DQUOTEと等しいです。 DQUOTE ext-predのないSPとVCHARに関する引用文字列はここで>を定義するのではなく、<Extension規制述部と等しいです。
(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)を構成しました。
4.2 Interpretation of feature predicate syntax
4.2 特徴述部構文の解釈
A feature set predicate is described by the syntax production for ' filter'.
特徴セット述部は'フィルタ'のための構文生産で説明されます。
4.2.1 Filter syntax
4.2.1 フィルタ構文
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").
'フィルタ'が簡単な特徴比較と定義される、('項目、'任意のパラメタ値で合成フィルタ('and'、'or'、'not')であって、飾り付けをされた下を見てください("q=qvalue"を含んでいて)。
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'の論理的なANDは'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)は'fn'までのフィルタ値'f1'、'f2'の論理的なORです。 すなわち、それは少なくともそれらのフィルタによって表された述部の1つを満たすどんな特徴収集でも満足しています。
Klyne Standards Track [Page 12] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[12ページ]RFC2533は1999年3月にセットを特集します。
(! 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'によって表された述部を満たさないどんな特徴収集でもsatusfiedされます。
4.2.2 Feature comparison
4.2.2 特徴比較
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<=値)は特徴が、より'値'以下であるなら供給された'値'、およびマッチがある'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.
そして、 より少なさ、-、すばらしさ、-、テストは数値でない特徴値で実行されるかもしれませんが、この仕様で非数値における関係を定義するよう命令してはいけないとき、一般に、それらは平等テストに達します。 特定のアプリケーションが特定の特徴タグの上に関係を命令しながらそのようなものを定義するかもしれませんが、そのような定義が範囲を超えている、(順応に必要でない、)、この仕様。
4.2.3 Feature tags
4.2.3 特徴タグ
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.
認識されていない特徴タグが特徴セット述部処理の間に遭遇するなら、それは遭遇するべきです、それでも、正統の特徴タグとして、処理されてください。 特徴セットマッチング規則は、新機能タグが既存の能力主張の正当性に影響しないで紹介されるのを許容するように設計されています。
Klyne Standards Track [Page 13] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[13ページ]RFC2533は1999年3月にセットを特集します。
4.2.4 Feature values
4.2.4 特徴値
A feature may have a number, Boolean, token or string value.
特徴に、ブール数、象徴またはストリング値があるかもしれません。
4.2.4.1 Boolean values
4.2.4.1 ブール値
A Boolean is simply a token with two predefined values: "TRUE" and "FALSE". (Upper- or lower- case letters may be used in any combination.)
Aブールであることは、単に2つの事前に定義された値がある象徴です: 「本当に」と「虚偽。」 (上側の、または、低いケース手紙はどんな組み合わせにも使用されるかもしれません。)
4.2.4.2 Numeric values
4.2.4.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」表された値は「m」が割られた「n」です。 したがって、↓これはすべてNo.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**)
3/+2, 15/-10 (有効な**ではなく、**)
4.2.4.3 Token values
4.2.4.3 象徴値
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.
象徴値は上に与えられた'象徴'のための構文に従う手紙、ケタ、および'--'キャラクタのあらゆる系列です。 それは何らかの(不特定)の値を表す名前です。
Klyne Standards Track [Page 14] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[14ページ]RFC2533は1999年3月にセットを特集します。
4.2.4.4 String values
4.2.4.4 ストリング値
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]).
このメモで定義されたストリングの意味論は象徴のためのものが評価するのと同じです。 しかし、ストリングははるかに大きいバラエティーの内部の形式を許容します、そして、特定のアプリケーションはここで与えられたものを越える方法で内容を解釈するのを選ぶかもしれません。 そのような解釈がどこで可能であるか、そして、許容記号列の書式と対応する解釈はメディア特徴登録で示されるべきです。(RFC2506[3])単位で。
4.2.5 Notational conveniences
4.2.5 記号法の利器
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=[1E、2Eの…アン]-->(| (t=[1E])(T=[2E])… (T=[アン]))(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.
表現: (紙サイズ=[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])
4.3 Feature set definition example
4.3 特徴セット定義の例
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:
↓これは多くの画像寸法と解決組み合わせについて説明する特徴述部に関する例です、'写真x'、'写真y'、'Res-x'、および'Res-y'特徴タグの登録と使用を推定して:
(| (& (Pix-x=1024)
(| (& (写真-x=1024)
Klyne Standards Track [Page 15] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[15ページ]RFC2533は1999年3月にセットを特集します。
(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 )
(写真-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)))) ((写真-x=800)(写真-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、((写真-x=640)(写真-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)
5. Matching feature sets
5. 合っている特徴セット
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:
この手順が確かに利くように、標準形に述部を減らさなければなりません。 ここで使用された標準形は「離接的な正規形」です。 離接的な正規形のための構文は以下の通りです。
Klyne Standards Track [Page 16] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[16ページ]RFC2533は1999年3月にセットを特集します。
filter = orlist
orlist = "(" "|" andlist ")" / term
andlist = "(" "&" termlist ")" / term
termlist = 1*term
term = "(" "!" simple ")" / simple
/andlist=「(「“!"簡単な」)」という1*用語termlist=用語=「("“&" termlist")」/用語用語/簡単な状態で「(「「|」 andlist」)」という=orlist orlist=をフィルターにかけてください。
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について説明しました。 したがって、canonicalizedフォームはほとんどの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.
提案に、述部のための「条項のフォーム」は「論理積正規形」と同様です、分裂(論理的なORs)の接続詞(論理的なAND)であり。 ここで使用された関連するセットマッチングを特徴とするように、より一層合ったフォームは結びつき(ANDs)の論理的な分裂(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.
標準形のこの考慮が本当に必要ですか? 結局、特徴述部はただ論理式なんでしょう? さて、いいえ: 特徴述部は'項目'によって特徴述部構文で表された原始の特徴価値テスト(比較)を含む論理式です。 TRUEかFALSE、独自にであるこれらのテストをすべて思うことができるなら、それぞれを原子的命題と見なすことができるでしょうに、そして、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.
しかし、一般に、同じ特徴タグが'項目'という1つ以上の述部に現れるかもしれないので、同じくらい独立していた状態でテストを見なすことができません。 本当に、相互依存が特徴セットマッチングのどんな重要な応用でも必要です、そして、これらの依存を得るのは重要です(例えば、送付者が供給できる解決のセットは受取人が扱うことができる解決のセットを重ね合わせますか?)。 したがって、私たちは代数的な操作のためのいくつかの付則でPredicate Calculusの要素に対処しなければなりません。
A description of both the Propositional and Predicate calculi can
be found in [12].
[12]でPropositionalとPredicate微積分学の両方の記述を見つけることができます。
Klyne Standards Track [Page 17] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[17ページ]RFC2533は1999年3月にセットを特集します。
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.
私たちは、これらの付則が複雑にされるよりなじみがないのを示すことを目指します。 特徴述部の工事と使用は実際に完全に一般化されたPredicate Calculusに対処する複雑さのいくつかを避けます。
5.1 Feature set matching strategy
5.1 特徴セットマッチング戦略
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は分類されて、マージは最小のフォームへの様々な規制です。 この過程は許容できる範囲の特徴値のための減少している表現、または値のFALSEを含む表現をもたらします。(それは、特徴値のどんな組み合わせも規制を満たすことができないという(その場合、対応する接続詞を決して満たすことができません)指示です)。
7. If the remaining disjunction contains at least one satisfiable
conjunction, then the constraints are shown to be satisfiable.
7. 残っている分裂が少なくとも1つのsatisfiable接続詞を含んでいるなら、規制は、satisfiableになるように示されます。
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.
結果として起こる特徴の声明がさらなる可能な合っている操作のためにセットしたので、それが非空であるならこの手順で得られた最終的な表現は使用できます。 付加的な機能に結合するための出発点が、規制述部にメッセージ移行経路のいくつかの実体の能力によって抑制される特徴セットを決定するように設定したので、すなわち、それを使用できます。
Klyne Standards Track [Page 18] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[18ページ]RFC2533は1999年3月にセットを特集します。
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.
以下に注意してください。 提示されるように、特徴タグ比較を結合して、unsatisfiable接続詞を排除する前に、過程に合っている特徴は離接的な正規形のすべての接続詞を評価します(そして、店)。 代替的アプローチは、低いメモリシステムにおいて、可能であり、それぞれの正規形接続詞がどれであるかで列挙されて、順番に評価されます、さらなる使用のために保有されるsatisfiableであるものだけで。
5.2 Formulating the goal predicate
5.2 目標述部を定式化すること。
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)
存在、(x): (P x) AND(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.
すなわち、このようにして説明されたセットが非空であるかどうか決定するために。
5.3 Replace set expressions
5.3は決まり文句を取り替えます。
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=[1E、2Eの…アン]-->(| (t=[1E])(T=[2E])… (T=[アン]))(Tは[R1..R2]と等しい)-->((T>はR1と等しいです)(T<=R2))、(T=[E])--、>。(T=E)
5.4 Move logical negations inwards
5.4は論理的な否定内部を動かします。
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:
これは以下の変換規則の繰り返された応用で達成されます:
Klyne Standards Track [Page 19] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[19ページ]RFC2533は1999年3月にセットを特集します。
(! (& 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つの規則が拡張型のド・モーガンの法則です、そして、3番目は二重否定の除去です。
5.5 Replace comparisons and logical negations
5.5は比較と論理的な否定を取り替えます。
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)
(B=C)(=B)、=>(=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.
これらの規則は目標述部を評価できる論理声明のコアボディーを形成します。 これらの声明が表されるフォームは効果的な述部合っているアルゴリズム(すなわち、輪にするか、または必ず有効な結果を見つけるもの)がわかるのに重要です。 これらの規則を定式化することにおける第一歩は原始の述部の枠組みを簡素化することです。
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:
1組の原始の述部はこれらの4つのケースを得ることができます:
(LE a b): 'a' is less than or equal to 'b'.
(GE a b): 'a' is greater than or equal to 'b'.
(LE a b): 'a'は、より'b'以下です。 (GE a b): 'a'はそう以上です。'b'。
The four cases described above are prepresented by the following combinations of primitive predicate values:
上で説明された4つのケースが原始の述語値の以下の組み合わせで前提示されます:
Klyne Standards Track [Page 20] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[20ページ]RFC2533は1999年3月にセットを特集します。
(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)
(LE a b) (GE a b)| 関係---------------------------------- 本当の偽| (LT a b) 本当である、本当| (EQ a b) 誤り、本当| (GT a b) 誤った偽| (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 a b)(>はbと等しい)-->(GE a b)(=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) )
(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)
((=b))-->(| (NL a b)(NG a b))((<=b))-->(NL a b)((>=b))-->。(NG a b)
Thus, we have rules to transform all comparisons and logical negations into combinations of just 4 relational operators.
したがって、私たちには、すべての比較と論理的な否定をちょうど4つの関係演算子の組み合わせに変える規則があります。
5.6 Conversion to canonical form
5.6 標準形への変換
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) -->、(| (A2 B1 B2…Bn): (A1 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です)
Klyne Standards Track [Page 21] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[21ページ]RFC2533は1999年3月にセットを特集します。
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.
これから、各接続詞('(…)')は別々に処理されます。 これらのひとりだけが、元の目標がsatisfiableなようにsatisfiableである必要があります。
(A textbook conversion to clausal form [5,11] uses slightly different rules to yield a "conjunctive normal form".)
(条項のフォーム[5、11]への教科書変換は「論理積正規形」をもたらすのにわずかに異なった規則を使用します。)
5.7 Grouping of feature predicates
5.7 特徴述部の組分け
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')に従って、簡単な述部は分類されます。
5.8 Merge single-feature constraints
5.8 マージ単独形体規制
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に決議されています)わかっているなら、含んでいる接続詞は、satisfiableでなく、捨てられるかもしれません。 さもなければ、結果として起こる記述は特徴セット定義のその特定の結びつきの最小量のフォームです。
Klyne Standards Track [Page 22] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[22ページ]RFC2533は1999年3月にセットを特集します。
5.8.1 Rules for simplifying ordered values
5.8.1 命令された値を簡素化するための規則
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 f a)(LE f b)--、>、(LE f a)、<はbと等しいです(LE f b)、そうでない、(LE f a)(GE f b)-->FALSE、<b、(LE f a)(NL f b)-->FALSE、<=b、(LE f a)(NG f b)--、>、(<b(NG f b)の、そして、そうでないLE f a)
(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 f a)(GE f b)--、>、(GE f a)、>はbと等しいです(GE f b)、そうでない、(GE f a)(NL f b)--、>、(GE f a)a>b(NL f b)で、そうでない、(GE f a)(NG f b)-->FALSE、>=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
(NL f a)(NL f b)--、>、(NL f a)、>はbと等しいです(NL f b)、そうでない、(NL f a)(NG f b)-->FALSE、>=b
(NG f a) (NG f b) --> (NG f a), a<=b
(NG f b), otherwise
(NG f a)(NG f b)--、>、(<=b(NG f b)の、そして、そうでないNG f a)
5.8.2 Rules for simplifying unordered values
5.8.2 順不同の値を簡素化するための規則
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
(LE f a)(LE f b)--、>、(a=b FALSEの、そして、そうでないLE f a)、(LE f a)(GE f b)--a!>FALSE、=b、(LE f a)(NL f b)--、>、(a!LE f a)=b FALSEで、そうでない、(LE f a)(NG f b)--、>、(=b FALSEの、そして、そうでないLE f a)
(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 f a)(GE f b)--、>、(a=b FALSEの、そして、そうでないGE f a)、(GE f a)(NL f b)--、>、(a!GE f a)=b FALSEで、そうでない、(GE f a)(NG f b)--、>、(a!GE f a)=b FALSEで、そうではありません
Klyne Standards Track [Page 23] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[23ページ]RFC2533は1999年3月にセットを特集します。
(NL f a) (NL f b) --> (NL f a), a=b
(NL f a) (NG f b) --> (NL f a), a=b
(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
(NG f a)(NG f b)--、>、(NG f a)、a=b
6. Other features and issues
6. 他の特徴と問題
6.1 Named and auxiliary predicates
6.1 命名されて補助の述部
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) 命名の可能な基礎を提供して、登録はセットを特集します。
6.1.1 Defining a named predicate
6.1.1 命名された述部を定義すること。
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.
以下に注意してください。 個々の特徴値と同様に特徴セットのための登録を作成する何らかの提案がありました。 そのような登録は、これらの特徴セットに対応する命名された述部を能力主張の環境に取り入れるのに使用されるかもしれません。 この考えのさらなる議論はこのメモの範囲を超えています。
Klyne Standards Track [Page 24] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[24ページ]RFC2533は1999年3月にセットを特集します。
6.1.2 Invoking named predicates
6.1.2 述部という呼び出し
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-predはfname*param param=exprと等しいです。
The number of parameters must match the definition of the named predicate that is invoked.
パラメタの数は呼び出される命名された述部の定義に合わなければなりません。
6.1.3 Auxiliary predicates in a filter
6.1.3 フィルタの補助の述部
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.
以下に注意してください。 帰納的述語は受入れられません。 見る規則はこれを確実にするべきです。
6.1.4 Feature matching with named predicates
6.1.4 命名された述部がある特徴マッチング
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のボディーを代入するとき、述部本体の中の仮パラメタの例を実施のポイントから対応する実引数に取り替えなければなりません。
Klyne Standards Track [Page 25] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[25ページ]RFC2533は1999年3月にセットを特集します。
6.1.5 Example
6.1.5 例
This example restates that given in section 4.3 using an auxiliary predicate named 'Res':
この例はセクション4.3で'Res'という補助の述部を使用することで与えられたそれを言い直します:
(| (& (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
(| ((写真-x=1024)(写真-y=768)(Res Res-x Res-y))((写真-x=800)(写真-y=600)(Res Res-x Res-y)); q=0.9((写真-x=640)(写真-y=480)(Res Res-x Res-y));q=0.8)どこ(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)))終わり
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"が、命名された述部のボディーが同様に命名された特徴値に参照をつけるのを防ぐことに注意してください。
6.2 Unit designations
6.2の名称
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).
いくつかの例外的な場合には、与えられた特徴の測定の単位単位で異なったコンベンションがあるかもしれません。 例えば、解決はインチ(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].
特徴タグの登録は、特徴のための測定の標準の単位を示して、また、使用されるどんな交互のユニットと対応するユニット指示子も示します、RFC2506[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.
したがって、特徴述部('(res=200)')は解決のための測定の標準の単位が'dpcm'であるなら1センチメートルあたり200のドットの解決を示すのに使用されるでしょう、そして、'(res=72dpi)'は、1インチあたり72のドットを示すのに使用されるかもしれません。
Klyne Standards Track [Page 26] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[26ページ]RFC2533は1999年3月にセットを特集します。
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.
これは、この簡単な例における生まれながらのふるまいであるように見えますが、より一般的な場合における追加複雑さを引き起こす場合があります。 それに従って、これは必要であるか通常のふるまいであると考えられません。 関するアプリケーションがどんな与えられた特徴のためにも一貫したユニットを採用することによって一貫した特徴処理を確実にすると推定されます。
6.3 Unknown feature value data types
6.3 未知の特徴値のデータ型
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.
特定のアプリケーションは、そのような値に関連している特徴タグを、認識して、処理するかもしれません。 今後の活動はそれらが彼らの特性に関する内蔵の知識を含まないアプリケーションで使用されるのを許容する方法で新機能値のデータ型を紹介する方法を定義するかもしれません。
7. Examples and additional comments
7. 例と追加コメント
7.1 Worked example
7.1 扱われた例
This example considers sending a document to a high-end black-and- white fax system with the following receiver capabilities:
そして、この例が、上位黒にドキュメントを送ると考える、-、-以下の受信機能力でファックスシステムを空白にしてください:
Klyne Standards Track [Page 27] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[27ページ]RFC2533は1999年3月にセットを特集します。
(& (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):
論理的なOR演算(形式-1OR形式-2OR形式-3について説明する)でこれらの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)(灰色の=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]と等しい))、(|、((dpi=300)(灰色の=2)(画像符号化はMRと等しいです)((dpi=200)(=2を灰色にします)(画像符号化=[MH、MMR]))、((dpi=300)
Klyne Standards Track [Page 28] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[28ページ]RFC2533は1999年3月にセットを特集します。
(color<=256)
(image-coding=JPEG) ) ) )
(色の<=256)(画像符号化は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..dpi..灰色..色..画像符号化..等しい..画像符号化..dpi..灰色..画像符号化..等しい..dpi..灰色..画像符号化..等しい..画像符号化..dpi..色..画像符号化..等しい
--> 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..dpi..灰色..色..画像符号化..等しい..画像符号化..dpi..灰色..画像符号化..等しい..dpi..灰色..画像符号化..等しい..画像符号化..dpi..色..画像符号化..等しい
--> (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..dpi..灰色..色..画像符号化..等しい..画像符号化..dpi..灰色..画像符号化..等しい..dpi..灰色..画像符号化..dpi..灰色..画像符号化..dpi..色..画像符号化..等しい
--> 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))
Klyne Standards Track [Page 29] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[29ページ]RFC2533は1999年3月にセットを特集します。
(& (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..灰色..色..画像符号化..等しい..dpi..灰色..画像符号化..等しい..dpi..灰色..画像符号化..dpi..灰色..画像符号化..dpi..色..画像符号化..等しい dpi..灰色..色..画像符号化..等しい..dpi..灰色..画像符号化..等しい..dpi..灰色..画像符号化..dpi..灰色..画像符号化..dpi..色..画像符号化..等しい dpi..灰色..色..画像符号化..等しい..dpi..灰色..画像符号化..等しい..dpi..灰色..画像符号化..dpi..灰色..画像符号化..dpi..色..画像符号化..等しい )
--> ... 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..灰色..色..画像符号化..等しい..dpi..灰色..画像符号化..等しい..dpi..灰色..色..画像符号化..等しい..dpi..灰色..画像符号化..等しい..dpi..灰色..色..画像符号化..等しい..dpi..灰色..画像符号化..等しい; dpi..灰色..色..画像符号化..等しい..dpi..灰色..画像符号化..等しい..dpi..灰色..色..画像符号化..等しい..dpi..灰色..画像符号化..等しい..dpi..灰色..色..画像符号化..等しい..dpi..灰色..画像符号化..等しい; 電子コード化はMR) (dpi=200)(灰色=2)(画像符号化=MMR)と等しいです((dpi=200)(灰色=2)(色の=0)(画像符号化はMHと等しいです)(dpi=300)(色の<=256)(画像符号化はJPEGと等しいです))。 ((dpi=200)(灰色=2)(色の=0)(画像符号化=MR)
Klyne Standards Track [Page 30] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[30ページ]RFC2533は1999年3月にセットを特集します。
(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と等しいです)(dpi=300)(色の<=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..dpi..灰色..灰色..色..画像符号化..等しい..画像符号化..等しい..dpi..dpi..灰色..灰色..色..画像符号化..等しい..画像符号化..等しい..など..dpi..dpi..灰色..色..色..画像符号化..等しい..画像符号化..等しい
--> Combine feature tag comparisons and eliminate unsatisfiable
conjunctions:
-->は特徴タグ比較を結合して、unsatisfiable接続詞を排除します:
(| (& (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.
したがって、私たちは、送付者と受信機オプションのこの組み合わせが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 受信機が色('(色の=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です。)
7.2 A note on feature tag scoping
7.2 特徴タグの見るのに関する注
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セット述部の解釈の何らかの追加論評を含みます。 それは、以前に説明されることを、広げてもいませんし、変更もしません。 むしろ、それは、可能な誤解の領域をはっきりさせるのを試みます。
Klyne Standards Track [Page 31] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[31ページ]RFC2533は1999年3月にセットを特集します。
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]) ) )
(((MRC-モード=1)(しまサイズ=256))(| ((画像符号化はJBIG-2レベルと等しいです)(しまサイズ=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形式にそれを適用できます、そして、別々にMRCデータの一部として現れるかもしれないJBIGイメージにそれを適用できます。
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:
1は、適用されるとこの例が256のしまのサイズについて説明するとMRC画像形式に想像して、MRCフォーマット済みデータの中のJBIG-2-LEVEL符号化画像に適用されると、128の別々のしまのサイズに想像するかもしれません。 しかし、そのように、働いていません: 使用される述部は、ブール論理の正常な法則に従って、以下の通り変えられるでしょう:
--> [flatten nested (&...)]:
(& (MRC-mode=1) (stripe-size=256)
(| (& (image-coding=JBIG-2-LEVEL) (stripe-size=128) )
(image-coding=[MH,MR,MMR]) ) )
-->[入れ子にされた状態で(…)、平らになります]: ((MRC-モード=1)(しまサイズ=256)(| ((画像符号化はJBIG-2レベルと等しいです)(しまサイズ=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モード=1)(しまサイズ=256)((画像符号化はJBIG-2レベルと等しいです)(しまサイズ=128))((MRC-モード=1)(しまサイズ=[0 .256])(画像符号化=[MH、MR、MMR])))
Klyne Standards Track [Page 32] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[32ページ]RFC2533は1999年3月にセットを特集します。
--> [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-モード=1)(256(しまサイズ=128)(画像符号化はJBIG-2レベルと等しいです)((MRC-モード=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]) ) )
((MRC-モード=1)(しまサイズ=256)(画像符号化=[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-モード=1)(MRC-しまサイズ=256))(| ((画像符号化はJBIG-2レベルと等しいです)(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]) ) )
(|、((MRC-モード=1)(256(JBIG-しまサイズ=128)(画像符号化はJBIG-2レベルと等しいです)((MRC-モード=1)(MRC-しまサイズ=256)(画像符号化=[MH、MR、MMR]))の)MRC-しまサイズ=)
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つ未満の値を持っているかもしれません。
Klyne Standards Track [Page 33] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[33ページ]RFC2533は1999年3月にセットを特集します。
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.
イメージ送付者か受信機の特性はaによって説明されて、「特徴はセットした」という(正式にそうです)特徴収集のaセットです。 ここで、特徴セット述部は、それがイメージ受信機で扱うことができるセットに属すかどうか決定するために何らかの画像特徴収集に適用されます。
8. Security Considerations
8. セキュリティ問題
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.
そのようなシステムは、採用しているメカニズムをチェックするどんなメッセージの保全と信憑性も破る傾向があるでしょう、したがって、ゲートウェイを変換する形式の使用は問題が多いと判明するかもしれません。
9. Acknowledgements
9. 承認
Thanks are due to Larry Masinter for demonstrating the breadth of the media feature issue, and encouraging the development of some early thoughts.
感謝は、ラリーのため、メディアの幅を示すためのMasinterが問題を特徴とするということであり、いくつかの早めの考えの開発を奨励しています。
Klyne Standards Track [Page 34] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[34ページ]RFC2533は1999年3月にセットを特集します。
Many of the ideas presented derive from the "Transparent Content Negotiation in HTTP" work of Koen Holtman and Andy Mutz [4].
提示された考えの多くがクンHoltmanとアンディの「HTTPにおけるわかりやすい満足している交渉」仕事からMutz[4]を引き出します。
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、テッド・ハーディー、およびダンWingからさらなる役に立つ入力につながりました。 後での討論はIETF'conneg'ワーキンググループに動きました。そこでは、アル・ギルマンとクンHoltmanが特徴セット代数を洗練することの特に助けになりました。 好みと特定のユニットに対処するための考えはラリーMasinterによって勧められました。
This work was supported by Content Technologies Ltd and 5th Generation Messaging Ltd.
この仕事はContent Technologies Ltdと5番目のGeneration Messaging Ltd.によって支持されました。
10. References
10. 参照
[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.ハーディー、「メディアはタグ登録手順を特徴とする」BCP31、RFC2506、1999年3月。
[4] Holtman, K. and A. Mutz, "Transparent Content Negotiation in
HTTP", RFC 2295, March 1998.
[4]HoltmanとK.とA.Mutz、「HTTPにおけるわかりやすい満足している交渉」、RFC2295、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] (2番目の版)、W.F.ClocksinとC.S.メリッシュ、Springer Verlag、ISBN3-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.翼、「表示、印刷、およびファックスのためのメディア機能」RFC2534(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)」、RFC2251 1997年12月。
[8] Howes, T., "The String Representation of LDAP Search Filters",
RFC 2254, December 1997.
[8] ハウズ、T.、「LDAP検索フィルタのストリング表現」、RFC2254、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.、Gettys、J.、ムガール人、J.、Frytyk、H.、およびT.Bernersリー、「Hyptertextはプロトコルを何HTTP/1.1インチも移します、RFC2068、1997年1月。」
[10] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[10]クロッカー、D.、エディタ、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
Klyne Standards Track [Page 35] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[35ページ]RFC2533は1999年3月にセットを特集します。
[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] ピーターは、「論理、代数、およびデータベース」と灰色にして、エリス・ホーウッドはシリーズです: コンピュータとそれらのApplications、ISBN0-85312-709-3/0- 85312-803-3(エリスホーウッドLtd)、ISBN0-470-20103-7/0-470- 20259-9(ハルステッド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] 「論理とそのApplications」、コンピュータサイエンス、ISBN0-13-030263-5、1996のエドモンドBurkとエリック・フォクスレイ、Prentice Hall、Series
[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.、ヴェナブル、D.、Zilles(S.、パーソンズ、G.、およびJ.Rafferty)は「インターネットファックスのために形式をファイルします」、RFC2301、1998年3月。
[14] Apache content negotiation algorithm,
<http://www.apache.org/docs/content-negotiation.html>
[14] アパッチ内容交渉アルゴリズム、<http://docs/内容www.apache.org/negotiation.html>。
11. Author's Address
11. 作者のアドレス
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.
株式会社第5世代メッセージング株式会社フォーラム1 5ウォトリントン通り駅の道路Nettlebed Thealeヘンリーオンテムズの読書、全麦のKlyne満足している技術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、641 641が電送する1300+44 1491: +44 118 930、641 611がメールする1301+44 1491: GK@ACM.ORG
Klyne Standards Track [Page 36] RFC 2533 A Syntax for Describing Media Feature Sets March 1999
メディアを説明するための1構文あたりKlyne標準化過程[36ページ]RFC2533は1999年3月にセットを特集します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Klyne Standards Track [Page 37]
Klyne標準化過程[37ページ]
一覧
スポンサーリンク
