RFC2703 日本語訳
2703 Protocol-independent Content Negotiation Framework. G. Klyne. September 1999. (Format: TXT=42071 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Klyne Request for Comments: 2703 5GM/Content Technologies Category: Informational September 1999
Klyneがコメントのために要求するワーキンググループG.をネットワークでつないでください: 2703年の5GM/内容技術カテゴリ: 情報の1999年9月
Protocol-independent Content Negotiation Framework
プロトコルから独立している満足している交渉フレームワーク
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
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. MIME media types [1,2] provide a standard method for handling one major axis of variation, but resources also vary in ways which cannot be expressed using currently available MIME headers.
多くのインターネットアプリケーション・プロトコルには、それらが相互作用するリソースのための満足している交渉を提供する必要があります。 MIMEメディアタイプ[1、2]は変化の1本の主要な軸を取り扱いのための標準方法に提供しますが、また、リソースは現在手があいているMIMEヘッダーを使用することで表すことができない方法で異なります。
This memo sets out terminology, an abstract framework and goals for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed.
このメモは、プロトコルから独立している満足している交渉の用語、抽象的なフレームワーク、および目標を出して、扱われる必要があるかもしれないいくつかの専門的な問題を特定します。
The abstract framework does not attempt to specify the content negotiation process, but gives an indication of the anticipated scope and form of any such specification. The goals set out the desired properties of a content negotiation mechanism.
抽象的なフレームワークは、満足している交渉プロセスを指定するのを試みませんが、予期された範囲と用紙のどんなそのような仕様のしるしも与えます。 目標は満足している交渉メカニズムの必要な特性を出します。
Table of Contents
目次
1. Introduction.............................................2
1.1 Structure of this document ...........................3
1.2 Discussion of this document ..........................3
2. Terminology and definitions..............................3
3. Framework................................................7
3.1 Abstract framework for content negotiation ...........8
3.1.1 The negotiation process..........................9
3.2 Abstract model for negotiation metadata .............10
3.3 Text representation for negotiation metadata ........11
3.4 ASN.1 description of negotiation metadata ...........11
3.5 Protocol binding guidelines .........................11
4. Goals...................................................12
1. 序論…2 1.1 このドキュメントの構造…3 1.2 このドキュメントの議論…3 2. 用語と定義…3 3. フレームワーク…7 満足している交渉のための3.1の抽象的なフレームワーク…8 3.1 .1 交渉プロセス…9 交渉メタデータのための3.2抽象モデル…10 3.3 交渉メタデータのテキスト表現…11 3.4 交渉メタデータのASN.1記述…11 3.5 拘束力があるガイドラインについて議定書の中で述べてください…11 4. 目標…12
Klyne Informational [Page 1] RFC 2703 Protocol-independent Content Negotiation September 1999
2703年の[1ページ]RFCのプロトコルから独立している内容交渉1999年9月の情報のKlyne
4.1 Generic framework and metadata goals ................12
4.2 Protocol-specific deployment goals ..................12
5. Technical issues........................................14
5.1 Non-message resource transfers ......................14
5.2 End-to-end vs hop-by-hop negotiations ...............14
5.3 Third-party negotiation .............................15
5.4 Use of generic directory and resolution services ....15
5.5 Billing issues ......................................15
5.6 Performance considerations ..........................15
5.7 Confidence levels in negotiated options .............16
6. Security Considerations.................................16
6.1 Privacy .............................................16
6.2 Denial of service attacks ...........................17
6.3 Mailing list interactions ...........................17
6.4 Use of security services ............................17
6.5 Disclosure of security weaknesses ...................18
6.5.1 User agent identification.......................18
6.5.2 Macro viruses...................................18
6.5.3 Personal vulnerability..........................18
6.6 Problems of negotiating security ....................18
7. Acknowledgements........................................18
8. References..............................................19
9. Author's Address........................................19
10. Full Copyright Statement...............................20
4.1のジェネリックフレームワークとメタデータ目標…12 4.2 プロトコル特有の展開目標…12 5. 技術的な問題…14 5.1非メッセージリソースは移されます…14 5.2の終わりから終わり対ホップごとの交渉…14 5.3 第三者交渉…15 5.4 ジェネリックディレクトリと解決サービスの使用…15 5.5 支払い問題…15 5.6 パフォーマンス問題…15 5.7 交渉されたオプションにおける信用レベル…16 6. セキュリティ問題…16 6.1プライバシー…16 6.2 サービスの否定は攻撃されます…17 6.3 メーリングリスト相互作用…17 6.4 セキュリティー・サービスの使用…17 6.5 セキュリティ弱点の公開…18 6.5 .1 ユーザエージェント識別…18 6.5 .2 マクロウイルス…18 6.5 .3の個人的な脆弱性…18 セキュリティを交渉するという6.6の問題…18 7. 承認…18 8. 参照…19 9. 作者のアドレス…19 10. 完全な著作権宣言文…20
1. Introduction
1. 序論
A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact. While MIME media types [1, 2] provide a standard method for handling one major axis of variation, resources also vary in ways which cannot be expressed using currently available MIME headers.
多くのインターネットアプリケーション・プロトコルには、それらが相互作用するリソースのための満足している交渉を提供する必要があります。 また、MIMEメディアタイプ[1、2]が変化の1本の主要な軸を取り扱いのための標準方法に提供している間、リソースは現在手があいているMIMEヘッダーを使用することで表すことができない方法で異なります。
This memo sets out terminology, a framework and some goals for a protocol-independent content negotiation framework, and identifies some technical issues which may need to be addressed.
このメモは、プロトコルから独立している満足している交渉フレームワークの用語、フレームワーク、およびいくつかの目標を出して、扱われる必要があるかもしれないいくつかの専門的な問題を特定します。
The framework does not attempt to specify the content negotiation process; rather it gives an indication of the anticipated scope and form of any such specifications.
フレームワークは、満足している交渉プロセスを指定するのを試みません。 むしろそれは予期された範囲と用紙のどんなそのような仕様のしるしも与えます。
The statement of goals is intended to set out the desired properties of a content negotiation framework, while trying to avoid any assumption of the form that framework may take.
フレームワークが取るかもしれない形のどんな仮定も避けていようとしている間、目標の声明が満足している交渉フレームワークの必要な特性を出すことを意図します。
Klyne Informational [Page 2] RFC 2703 Protocol-independent Content Negotiation September 1999
2703年の[2ページ]RFCのプロトコルから独立している内容交渉1999年9月の情報のKlyne
1.1 Structure of this document
1.1 このドキュメントの構造
The main part of this memo addresses four main areas:
このメモの主部は4つの主な領域を扱います:
Section 2 defines some of the terms which are used with special meaning.
セクション2は特別な意味と共に使用される用語のいくつかを定義します。
Section 3 outlines a proposed framework for describing protocol- independent content negotiation.
セクション3は、プロトコルの独立している満足している交渉について説明するために提案されたフレームワークについて概説します。
Section 4 describes various goals for content negotiation.
セクション4は満足している交渉の様々な目標について説明します。
Section 5 discusses some of the technical issues which are raised by this document, with cross-references to other work where appropriate.
セクション5は適切であるところでこのドキュメントによって提起される専門的な問題のいくつかについて他の仕事への相互参照に論じます。
1.2 Discussion of this document
1.2 このドキュメントの議論
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. Terminology and definitions
2. 用語と定義
This section introduces a number of terms which are used with specific meaning in the content negotiation documents. Many of these have been copied and adapted from [5].
このセクションは満足している交渉ドキュメントでの特定の意味と共に使用される項数を導入します。 これらの多くが、[5]からコピーされて、適合させられました。
The terms are listed in alphabetical order.
用語はアルファベット順にリストアップされています。
Capability
An attribute of a sender or receiver (often the receiver)
which indicates an ability to generate or process a
particular type of message content.
Anが結果と考える特定のタイプに関するメッセージ内容を生成するか、または処理する能力を示す送付者か受信機(しばしば受信機)の能力。
Klyne Informational [Page 3] RFC 2703 Protocol-independent Content Negotiation September 1999
2703年の[3ページ]RFCのプロトコルから独立している内容交渉1999年9月の情報のKlyne
Characteristic
Some description of a sender or receiver which indicates a
possible capability or preference.
可能な能力か優先を示す送付者か受信機の独特のSome記述。
Choice message
A choice message returns a representation of some selected
variant or variants, together with the variant list of the
negotiable resource. It can be generated when the sender
has sufficient information to select a variant for the
receiver, and also requires to inform the receiver about
the other variants available.
A特選しているメッセージ選択メッセージはいくつかの選択された異形か異形の表現を返します、交渉可能なリソースの異形リストと共に。 送付者が、受信機のために異形を選択できるくらいの情報を持って、また、利用可能な他の異形に関して受信機を知らせるのを必要とするとき、それを生成することができます。
Connected mode
A mode of operation in which sender and receiver are
directly connected, and hence are not prevented from
definitively determining each other's capabilities. (See
also: Session mode)
送付者と受信機が直接接されて、したがって決定的に互いの能力を決定してもよい関連モードA運転モード。 (参照: セッションモード)
Content feature
(see Feature)
満足している特徴(特徴を見ます)
Content negotiation
An exchange of information (negotiation metadata) which
leads to selection of the appropriate representation
(variant) when transferring a data resource.
データリソースを移すとき適切な表現(異形)の選択につながる満足している交渉An情報交換(交渉メタデータ)。
Data resource
A network data object that can be transferred. Data
resources may be available in multiple representations
(e.g. multiple languages, data formats, size, resolutions)
or vary in other ways. (See also: Message, Resource)
データリソースAは移すことができるデータ・オブジェクトをネットワークでつなぎます。 データ源は、複数の表現(例えば、複数の言語、データ形式、サイズ、解決)で利用可能であるか、または他の方法で異なるかもしれません。 (参照: Resource、メッセージ)
Feature A piece of information about the media handling properties
of a message passing system component or of a data
resource.
メッセージ・パッシングシステムの部品かデータリソースの特性を処理するメディアの情報のA断片を特徴としてください。
Feature tag
A name that identifies a "feature".
「特徴」を特定するタグA名を特徴としてください。
Feature set
Information about a sender, recipient, data file or other
participant in a message transfer which describes the set
of features that it can handle.
それが扱うことができる特徴のセットについて説明するメッセージ転送で送付者、受取人、データファイルまたは他の関係者に関するセット情報を特徴としてください。
Where a 'feature' describes a single identified attribute
of a resource, a 'feature set' describes full set of
possible attributes.
'特徴'がリソースのただ一つの特定された属性について説明するところでは、'特徴セット'は可能な属性のフルセットについて説明します。
Klyne Informational [Page 4] RFC 2703 Protocol-independent Content Negotiation September 1999
2703年の[4ページ]RFCのプロトコルから独立している内容交渉1999年9月の情報のKlyne
List message
A list message sends the variant list of a negotiable
resource, but no variant data. It can be generated when
the sender does not want to, or is not allowed to, send a
particular variant.
リストメッセージAリストメッセージは交渉可能なリソースにもかかわらず、異形データがない異形リストを送ります。 それは、送付者を生成されたくないと生成することができるか、または許容されていなくて、特定の異形を送ってください。
Media feature
information that indicates facilities assumed to be
available for the message content to be properly rendered
or otherwise presented. Media features are not intended to
include information that affects message transmission.
メディアはメッセージ内容が適切に表されるか、またはそうでなければ、提示されるために利用可能であると思われた施設を示す情報を特徴とします。 メディア機能がメッセージ送信に影響する情報を含んでいることを意図しません。
Message Data which is transmitted from a sender to a receiver,
together with any encapsulation which may be applied.
Where a data resource is the original data which may be
available in a number of representations, a message
contains those representation(s) which are actually
transmitted. Negotiation metadata is not generally
considered to be part of a message.
適用されるどんなカプセル化と共にも送付者から受信機まで伝えられるメッセージData。 データリソースが多くの表現で利用可能であるかもしれないオリジナルのデータであるところでは、メッセージは実際に伝えられるそれらの表現を含んでいます。 一般に、交渉メタデータはメッセージの一部であると考えられません。
Message data is distinguished from other transmitted data
by the fact that its content is fully determined before the
start of transmission.
内容がトランスミッションの始まりの前に完全に決定しているという事実によってメッセージデータは他の伝えられたデータと区別されます。
Negotiated content
Message content which has been selected by content
negotiation.
満足している交渉で選択された満足しているMessage内容を交渉しました。
Negotiation
(See: content negotiation)
交渉(: 満足している交渉を見ます)
Negotiable resource
A data resource which has multiple representations
(variants) associated with it. Selection of an appropriate
variant for transmission in a message is accomplished by
content negotiation between the sender and recipient.
それに関連している複数の表現(異形)がある交渉可能なリソースAデータリソース。 メッセージにおけるトランスミッションのための適切な異形の選択は送付者と受取人との満足している交渉で実行されます。
Negotiation metadata
Information which is exchanged between the sender and
receiver of a message by content negotiation in order to
determine the variant which should be transferred.
移されるべきである異形を決定するためにメッセージの送付者と受信機の間で満足している交渉で交換される交渉メタデータ情報。
Neighbouring variant
A particular representation (variant) of a variant resource
which can safely be assumed to be subject to the same
access controls as the variant resource itself. Not all
variants of a given variant resource are necessarily
neighbouring variants. The fact that a particular variant
同じアクセスを受けることがあると安全に思うことができる異形リソースの隣接している異形A特定の表現(異形)は異形リソース自体として制御されます。 与えられた異形リソースのすべての異形が必ず隣接している異形であるというわけではありません。 事実はそのa特定の異形です。
Klyne Informational [Page 5] RFC 2703 Protocol-independent Content Negotiation September 1999
2703年の[5ページ]RFCのプロトコルから独立している内容交渉1999年9月の情報のKlyne
is or is not a neighbouring variant has implications for
security considerations when determining whether that
variant can be sent to a receiver in place of the
corresponding variant resource. It may also have
implications when determining whether or not a sender is
authorized to transmit a particular variant.
あるか、対応する異形リソースに代わってその異形を受信機に送ることができるかどうか決定するとき隣接している異形にはセキュリティ問題のための意味があるということではありません。 また、送付者が特定の異形を伝えるのに権限を与えられるかどうか決定するとき、それには意味があるかもしれません。
Preference
An attribute of a sender or receiver (often the receiver)
which indicates an preference to generate or process one
particular type of message content over another, even if
both are possible.
両方が可能であっても1つの特定のタイプに関するメッセージ内容を別のものの上に生成するか、または処理するために優先を示すAnが結果と考える送付者か受信機(しばしば受信機)の好み。
Receiver A system component (device or program) which receives a
message.
メッセージを受け取る受信機Aシステムの部品(デバイスかプログラム)。
Receiver-initiated transmission
A message transmission which is requested by the eventual
receiver of the message. Sometimes described as 'pull'
messaging. E.g. an HTTP GET operation.
メッセージの最後の受信機によって要求される受信機で開始しているトランスミッションAメッセージ送信。 時々'牽引力'メッセージングとして記述されています。 例えば、HTTP GET操作。
Resource A document, data file or facility which is accessed or
transmitted across a network. (See also: Data resource)
ネットワークの向こう側にアクセスされるか、または伝えられるリソースAドキュメント、データファイルまたは施設。 (参照: データリソース)
Sender A system component (device or program) which transmits a
message.
送信する送付者Aシステムの部品(デバイスかプログラム)。
Sender-initiated transmission
A message transmission which is invoked by the sender of
the message. Sometimes described as 'push' messaging. E.g.
sending an e-mail.
メッセージ送信者によって呼び出される送付者によって開始されたトランスミッションAメッセージ送信。 時々'プッシュ'メッセージングとして記述されています。 例えば、メールを送ること。
Session mode
A mode of message transmission in which confirmation of
message delivery is received by the sender in the same
application session (usually the same transport connection)
that is used to transmit the message. (See also: connected
mode, store and forward mode)
メッセージ送信のセッションモードAモードはメッセージを送るのに使用されるのと同じアプリケーションセッション(通常同じ輸送接続)のときにメッセージ配送のどの確認に送付者によって受け取られるか。 (参照: 関連モード、店、および前進のモード)
Store and forward mode
A mode of message transmission in which the message is held
in storage for an unknown period of time on message
transfer agents before being delivered.
提供される前に未知の期間の間メッセージがメッセージ転送エージェントにストレージで保持されるメッセージ送信のモードAモードを保存して、進めてください。
Syntax The form used to express some value; especially the format
used to express a media feature value, or a feature set.
(See also: feature value, feature set, type.)
フォームが何らかの値を言い表すのに使用した構文。 特にメディア機能が評価する急行、または特徴セットに使用される形式。 (参照: 特徴値、特徴セットはタイプされます。)
Klyne Informational [Page 6] RFC 2703 Protocol-independent Content Negotiation September 1999
2703年の[6ページ]RFCのプロトコルから独立している内容交渉1999年9月の情報のKlyne
Transmission
The process of transferring a message from a sender to a
receiver. This may include content negotiation.
a受信機送付者からこれまでメッセージを移すプロセスが含むかもしれないトランスミッションは交渉を満足させます。
Type The range of values that can be indicated by some
identifier of variable; especially the range of values
that can be indicated by a feature tag. (See also:
feature, syntax.)
変数に関する何らかの識別子で示すことができる値の範囲をタイプしてください。 特に特徴タグで示すことができる値の範囲。 (参照: 特徴、構文。)
NOTE: this differs from usage employed by the LDAP/X.500
directory community, who use the terms "attribute type" to
describe an identifier for a value in a directory entry,
and "attribute syntax" to describe a range of allowed
attribute values.
以下に注意してください。 これはLDAP/X.500ディレクトリ共同体によって使われた用法と異なっています。共同体は、ディレクトリエントリの値のための識別子について説明するのに「属性タイプ」という用語を使用して、さまざまな許容属性値について説明するために「構文を結果と考えます」。
User agent
A system component which prepares and transmits a message,
or receives a message and displays, prints or otherwise
processes its contents.
メッセージを準備して、送るか、またはメッセージとディスプレイを受け止めるユーザエージェントAシステムの部品が、コンテンツを印刷するか、またはそうでなければ、処理します。
Variant One of several possible representations of a data
resource.
データリソースのいくつかの可能な表現の異形1つ。
Variant list
A list containing variant descriptions, which can be bound
to a negotiable resource.
交渉可能なリソースに縛ることができる異形記述を含む異形リストAリスト。
Variant description
A machine-readable description of a variant resource,
usually found in a variant list. A variant description
contains a variant resource identifier and various
attributes which describe properties of the variant.
通常、異形リストで見つけられた異形リソースの異形の記述のA機械可読な記述。 異形記述は異形リソース識別子と異形の特性について説明する様々な属性を含んでいます。
Variant resource
A data resource for which multiple representations
(variants) are available.
複数の表現(異形)が利用可能である異形リソースAデータリソース。
3. Framework
3. フレームワーク
For the purposes of this document, message transmission protocol capabilities are explicitly disregarded: it is presumed that these will be dealt with separately by some orthogonal mechanism.
このドキュメントの目的のために、メッセージトランスミッションプロトコル能力は明らかに無視されます: これらが別々に何らかの直交したメカニズムによって対処されると推定されます。
Klyne Informational [Page 7] RFC 2703 Protocol-independent Content Negotiation September 1999
2703年の[7ページ]RFCのプロトコルから独立している内容交渉1999年9月の情報のKlyne
Content negotiation covers three elements:
満足している交渉は3つの要素をカバーしています:
1. expressing the capabilities of the sender and the data resource to
be transmitted (as far as a particular message is concerned),
1. 送付者とデータリソースが伝えられる(特定のメッセージに関する限り)能力を言い表すこと。
2. expressing the capabilities of a receiver (in advance of the
transmission of the message), and
そして2. 受信機(メッセージの伝達の前の)の能力を言い表す。
3. a protocol by which capabilities are exchanged.
3. 能力が交換されるプロトコル。
These negotiation elements are addressed by a negotiation framework incorporating a number of design elements with dependencies shown:
これらの交渉要素は示される依存で多くのデザイン要素を組み込む交渉フレームワークによって扱われます:
[ Abstract ] [ Abstract ]
[negotiation] [ negotiation ]
[ process ] [ metadata ]
| |
V V
[Negotiation] [ Negotiation ]
[ protocol ] [ metadata ]
[ binding ] [representation]
| |
------- -------
| |
V V
[Application protocol]
[ incorporating ]
[content negotiation ]
[抽象的][抽象的な]の[交渉][交渉][プロセス][メタデータ]| | V V[交渉][交渉][プロトコル][メタデータ][拘束力がある][表現]| | ------- ------- | | V V[アプリケーション・プロトコル][盛込み][満足している交渉]
Within this overall framework, expressing the capabilities of sender and receiver is covered by negotiation metadata. The protocol for exchanging capabilities is covered by the abstract negotiation framework and its binding to a specific application protocol.
この総合的なフレームワークの中では、送付者と受信機の能力を言い表すのは交渉メタデータでカバーされています。 能力を交換するためのプロトコルは、抽象的な交渉フレームワークでカバーされて、それは特定のアプリケーション・プロトコルに付くことです。
Application protocol independence is addressed by separating the abstract negotiation process and metadata from concrete representations and protocol bindings.
アプリケーション・プロトコル独立は、具体的な表現とプロトコル結合と抽象的な交渉プロセスとメタデータを切り離すことによって、扱われます。
3.1 Abstract framework for content negotiation
3.1 満足している交渉のための抽象的なフレームワーク
The negotiation framework provides for an exchange of negotiation metadata between the sender and receiver of a message which leads to determination of a data format which the sender can provide and the recipient can process. Thus, there are three main elements which are the subjects of the negotiation process and whose capabilities are described by the negotiation metadata: the sender, the transmitted data file format and the receiver.
交渉フレームワークは送付者が提供できるデータの形式の決断につながるメッセージの送付者と受信機の間の交渉メタデータの交換に備えます、そして、受取人は処理できます。 したがって、交渉プロセスの対象であり、能力が交渉メタデータによって説明される3つの主な要素があります: 送付者、伝えられたデータファイル形式、および受信機。
Klyne Informational [Page 8] RFC 2703 Protocol-independent Content Negotiation September 1999
2703年の[8ページ]RFCのプロトコルから独立している内容交渉1999年9月の情報のKlyne
The life of a data resource may be viewed as:
データリソースの寿命は以下として見なされるかもしれません。
(C) (T) (F)
[A]-->--[S]-->--[R]-->--[U]
(C)(T)(F)[A]-->--[S]-->--[R]-->--[U]
where:
どこ:
[A] = author of document
(C) = original document content
[S] = message sending system
(T) = transmitted data file (representation of (C))
[R] = receiving system
(F) = formatted (rendered) document data (presentation of (C))
[U] = user or consumer of a document
[A] = 正本内容[S]=ドキュメント(C)の作者=メッセージ送信システム(T)=がデータファイルを伝えた、((C))[R]=受電方式(F)=の表現がドキュメントデータをフォーマットした、(レンダリングされます)((C))[U]のプレゼンテーションはドキュメントのユーザか消費者と等しいです。
Here, it is [S] and [R] who exchange negotiation metadata to decide the form of (T), so these elements are the focus of our attention.
[R] [S]とだれが(T)のフォームについて決めるために交渉メタデータを交換するかというここの、ことであるので、これらの要素は私たちの留意の焦点です。
Negotiation metadata provided by [S] would take account of available document content (C) (e.g. availability of resource variants) as well as its own possible ability to offer that content in a variety of formats.
[S]によって提供された交渉メタデータはさまざまな形式でその内容を提供するそれ自身の可能な能力と同様に利用可能なドキュメント内容(C)(例えば、リソース異形の有用性)を考慮に入れるでしょう。
Negotiation metadata provided by [R] would similarly take account of the needs and preferences of its user [U] as well as its own capabilities to process and render received data.
[R]によって提供された交渉メタデータは同様に受信データを処理して、表すそれ自身の能力と同様にユーザ[U]の必要性と好みを考慮に入れるでしょう。
3.1.1 The negotiation process
3.1.1 交渉プロセス
Negotiation between the sender [S] and the receiver [R] consists of a series of negotiation metadata exchanges that proceeds until either party determines a specific data file (T) to be transmitted. If the sender makes the final determination, it can send the file directly. Otherwise the receiver must communicate its selection to the sender who sends the indicated file.
送付者[S]と受信機[R]との交渉は何れの当事者が、特定のデータファイル(T)が伝えられると決心するまで続く一連の交渉メタデータ交換から成ります。 送付者が最終的決定をするなら、それは直接ファイルを送ることができます。 さもなければ、受信機は示されたファイルを送る送付者に選択を伝えなければなりません。
This process implies an open-ended exchange of information between sender and receiver. Not every implementation is expected to implement this scheme with the full generality thus implied. Rather, it is expected that every concrete negotiation can be viewed as a subset of this process.
このプロセスは送付者と受信機の間の制限のない情報交換を含意します。完全な一般性がこのようにして含意されている状態であらゆる実装がこの体系を実装すると予想されるというわけではありません。 むしろ、このプロセスの部分集合としてあらゆる具体的な交渉を見なすことができると予想されます。
For example, Transparent Content Negotiation (TCN) [5] uses a model in which one of the following happens:
例えば、Transparent Content Negotiation(TCN)[5]は以下のどの1つが起こるかにモデルを使います:
o The recipient requests a resource with no variants, in which case
the sender simply sends what is available.
o 受取人は異形なしでリソースを要求します、その場合、送付者が単に利用可能なものを送ります。
Klyne Informational [Page 9] RFC 2703 Protocol-independent Content Negotiation September 1999
2703年の[9ページ]RFCのプロトコルから独立している内容交渉1999年9月の情報のKlyne
o A variant resource is requested, in which case the server replies
with a list of available variants, and the client chooses one
variant from those offered.
o 異形リソースは要求されています、そして、その場合、サーバは利用可能な異形のリストで返答します、そして、クライアントは提供されたものから1つの異形を選びます。
o The recipient requests a variant resource, and also provides
negotiation metadata (in the form 'Accept' headers) which allows
the server to make a choice on the client's behalf.
o 受取人は、異形リソースを要求して、また、サーバがクライアントに代わって選択をすることができる交渉メタデータ(フォームでは、ヘッダーを'受け入れる')を提供します。
Another, simpler example is that of fax negotiation: in this case the intended recipient declares its capabilities, and the sender chooses a message variant to match.
別のもの、より簡単な例はファックス交渉のものです: この場合、意図している受取人は能力を宣言します、そして、送付者は合うようにメッセージ異形を選びます。
Each of these can be viewed as a particular case of the general negotiation process described above. Similar observations can be made regarding the use of directory services or MIME ' Multipart/alternative' in conjunction with e-mail message transmission.
一般的な交渉プロセスの特定のケースが上で説明したようにそれぞれのこれらを見ることができます。 ディレクトリサービスかMIMEの使用'Multipart/代替手段'に関してメールメッセージ送信に関連して同様の観測をすることができます。
3.2 Abstract model for negotiation metadata
3.2 交渉メタデータのための抽象モデル
A simple but general negotiation framework has been described, which is based on the exchange of negotiation metadata between sender and recipient. The mechanism by which data is exchanged is not important to the abstract negotiation framework, but something does need to be said about the general form of the metadata.
簡単な、しかし、一般的な交渉フレームワーク(送付者と受取人の間の交渉メタデータの交換に基づいている)は説明されます。 データが交換されるメカニズムは抽象的な交渉フレームワークに重要ではありませんが、何かが、メタデータの一般的なフォームに関して言われている必要があります。
The terminology and definitions section of this document places constraints on the form of negotiation metadata, and the descriptions that follow should be read in conjunction with the definitions to which they refer.
このドキュメントの用語と定義部は交渉メタデータのフォームに規制を置きます、そして、続く記述はそれらが参照する定義に関連して読み込まれるべきです。
Negotiation metadata needs to encompass the following elements:
交渉メタデータは、以下の要素を包含する必要があります:
o Media feature: a way to describe attributes of a data resource.
o メディアは以下を特集します。 データリソースの属性について説明する方法。
o Feature set: a description of a range of possible media feature
combinations which can be: offered by a sender; represented by a
data file format; or processed by a receiver.
o 特徴はセットしました: 可能のメディアが以下の通りであることができる組み合わせを特徴とするのを1つの範囲の記述 送付者によって提供されます。 データファイル形式で、表されます。 または、受信機で、処理されています。
o One or more naming schemes for labelling media features and
feature sets. These should be backed up by some kind of
registration process to ensure uniqueness of names and to
encourage a common vocabulary for commonly used features.
o 1かメディアを特徴と特徴に分類することの体系をもう少し命名するのがセットします。 これらは、名前のユニークさを確実にして、一般的に使用された特徴のために一般的なボキャブラリーを奨励するためにある種の登録手続で支援されるべきです。
o A framework of data types for media features, indicating the range
and properties of value types which can be represented.
o 代理をされることができる値のタイプのメディア機能のためのデータ型のフレームワーク、範囲を示して、および特性。
Klyne Informational [Page 10] RFC 2703 Protocol-independent Content Negotiation September 1999
2703年の[10ページ]RFCのプロトコルから独立している内容交渉1999年9月の情報のKlyne
o A way to combine media features into feature sets, capable of
expressing feature dependencies within a feature set (e.g.
640x480 pixel size and 256 colours, or 800x600 pixel size and 16
colours).
o メディア機能を特徴に結合する方法はセットします、特徴セット(例えば、640×480画素サイズと256の色か、800×600画素サイズと16の色)の中に特徴の依存を示すことができます。
o Some way to rank feature sets based upon sender and receiver
preferences for different feature values.
o 特徴セットを格付けする何らかの方法が異なった特徴値のための好みを送付者と受信機に基礎づけました。
3.3 Text representation for negotiation metadata
3.3 交渉メタデータのテキスト表現
A concrete textual representation for media feature values and feature set descriptions would provide a common vocabulary for feature data in text-based protocols like HTTP and SMTP.
メディアが値と特徴セット記述を特徴とするので、具体的な原文の表現はHTTPとSMTPのようなテキストベースのプロトコルで一般的なボキャブラリーを特徴データに提供するでしょう。
In defining a textual representation, the issue of allowable character sets needs to be addressed. Whether or not negotiation metadata needs to support a full gamut of international characters will depend upon the framework of data types adopted for media features. As negotiation metadata would be used as a protocol element (not directly visible to the user) rather than part of the message content, support for extended character sets may be not required.
原文の表現を定義する際に、許容できる文字集合の問題は、扱われる必要があります。 国際的な人物の全域をサポートする交渉メタデータの必要性がデータ型のフレームワークによるかどうかがメディアのために特徴を採用しました。 交渉メタデータはメッセージ内容の一部よりむしろプロトコル要素(ユーザにとって、直接目に見えない)として使用されるでしょう、したがって、拡張文字集合のサポートが必要でないかもしれません。
A textual representation for negotiation metadata would imply a textual representation for media feature names, and also for expressions of the media feature combining algebra.
交渉メタデータの原文の表現は特徴が命名するメディア、および代数を結合するメディア機能の式についても原文の表現を含意するでしょう。
3.4 ASN.1 description of negotiation metadata
3.4 交渉メタデータのASN.1記述
For use with non-text-based protocols, an ASN.1 description and encoding designation for negotiation metadata could be helpful for incorporating the common negotiation framework into ASN.1-derived protocols like X.400, X.500, LDAP and SNMP.
非テキストベースのプロトコルによる使用のために、X.400、X.500、LDAP、およびSNMPのようなASN.1によって派生させられたプロトコルに一般的な交渉フレームワークを組み入れるのにおいて、ASN.1記述と交渉メタデータのための名称をコード化するのは役立っているかもしれません。
An ASN.1 description of negotiation metadata formats suggests that separate media feature naming scheme based on ISO object identifiers would be valuable.
交渉メタデータ形式のASN.1記述は、特徴命名体系がISOオブジェクト識別子に基礎づけた別々のメディアが有益であると示唆します。
3.5 Protocol binding guidelines
3.5 ガイドラインを縛るプロトコル
Specific protocol bindings will be needed to use the abstract framework for negotiation.
特定のプロトコル結合が、交渉に抽象的なフレームワークを使用するのに必要でしょう。
Details of protocol bindings would be beyond the scope of this work, but guidelines maybe not. (SASL might provide a useful model here.)
しかし、この範囲が扱う以遠、ガイドラインが多分そうしないなら、プロトコル結合の詳細はそうするでしょうに。 (SASLは役に立つモデルをここに提供するかもしれません。)
Klyne Informational [Page 11] RFC 2703 Protocol-independent Content Negotiation September 1999
2703年の[11ページ]RFCのプロトコルから独立している内容交渉1999年9月の情報のKlyne
4. Goals
4. 目標
These goals are presented in two categories:
これらの目標は2つのカテゴリで提示されます:
1. Negotiation framework and metadata goals which address the broad
goals of negotiation in a protocol-independent fashion.
1. プロトコルから独立しているファッションで交渉の広い目標を扱う交渉フレームワークとメタデータ目標。
2. Specific goals which relate to the deployment of negotiation in
the context of a specific protocol (e.g. relation to HTTP protocol
operations, cache interactions, security issues, existing HTTP
negotiation mechanisms, application to variant selection, etc.).
These would be addressed by a specific protocol binding for the
negotiation framework.
2. 特定のプロトコル(例えば、HTTPプロトコル操作、キャッシュ相互作用、安全保障問題、既存のHTTP交渉メカニズム、異形選択への適用などとの関係)の文脈における、交渉の展開に関連する明確な目標。 これらは交渉フレームワークで付く特定のプロトコルによって扱われるでしょう。
4.1 Generic framework and metadata goals
4.1 ジェネリックフレームワークとメタデータ目標
o A common vocabulary for designating features and feature sets.
o 特徴と特徴を指定するための一般的なボキャブラリーはセットします。
o A stable reference for commonly used features.
o 一般的に使用された特徴の安定した参照。
o An extensible framework, to allow rapid and easy adoption of new
features.
o 広げることができるフレームワーク、新機能の急速で簡単な採用を許すために。
o Permit an indication of quality or preference.
o 品質か好みのしるしを可能にしてください。
o Capture dependencies between feature values
o 特徴値の間の依存を得てください。
o A uniform framework mechanism for exchanging negotiation metadata
should be defined that can encompass existing negotiable features
and is extensible to future (unanticipated) features.
o 交渉メタデータを交換するための既存の交渉可能な特徴を取り囲むことができる、将来(思いがけない)の特徴に広げることができる一定のフレームワークメカニズムは、定義されるべきです。
o Efficient negotiation should be possible in both receiver
initiated ('pull') and sender initiated ('push') message
transfers.
o 効率的な交渉は両方の受信機の開始している('牽引力')と送付者の開始している('プッシュ')メッセージ転送で可能であるべきです。
o The structure of the negotiation procedure framework should stand
independently of any particular message transfer protocol.
o 交渉手順フレームワークの構造はどんな特定のメッセージ転送プロトコルの如何にかかわらず立つはずです。
o Be capable of addressing the role of content negotiation in
fulfilling the communication needs of less able computer users.
o それほど有能でないコンピュータユーザのコミュニケーションの必要性を実現させる際に満足している交渉の役割を扱うことができてください。
4.2 Protocol-specific deployment goals
4.2 プロトコル特有の展開目標
o A negotiation should generally result in identification of a
mutually acceptable form of message data to be transferred.
o 一般に、交渉は、移すために互いに許容しているフォームに関するメッセージデータの識別に結果として生じるべきです。
Klyne Informational [Page 12] RFC 2703 Protocol-independent Content Negotiation September 1999
2703年の[12ページ]RFCのプロトコルから独立している内容交渉1999年9月の情報のKlyne
o If capabilities are being sent at times other than the time of
message transmission, then they should include sufficient
information to allow them to be verified and authenticated.
o メッセージ送信の時間を除いて、時には能力を送るなら、それらは、それらが確かめられて、認証されるのを許容するために十分な情報を含むべきです。
o A capability assertion should clearly identify the party to whom
the capabilities apply, the party to whom they are being sent, and
some indication of their date/time or range of validity. To be
secure, capability assertions should be protected against
interception and substitution of valid data by invalid data.
o 能力主張は明確に、能力が適用されるパーティーを特定するべきです、それらが送られて、彼らの日付/時間のいくつかのしるしであるか及ぶ正当性のパーティー。 安全に、なるように、能力主張は無効のデータによって有効データの妨害と代替に対して保護されるべきです。
o A request for capability information, if sent other than in
response to delivery of a message, should clearly identify the
requester, the party whose capabilities are being requested, and
the time of the request. It should include sufficient information
to allow the request to be authenticated.
o メッセージの配送を除いて、送るなら、能力情報に関する要求は明確に、リクエスタ(能力が要求されていて、要求の時間であるパーティー)を特定するべきです。 それは、認証されるという要求を許すために十分な情報を含むべきです。
o In the context of a given application, content negotiation may use
one or several methods for transmission, storage, or distribution
of capabilities.
o 与えられたアプリケーションの文脈では、満足している交渉は能力のトランスミッション、ストレージ、または分配に1かいくつかのメソッドを使用するかもしれません。
o The negotiation mechanism should include a standardized method for
associating features with resource variants.
o 交渉メカニズムはリソース異形に特徴を関連づけるための標準化法を含んでいるはずです。
o Negotiation should provide a way to indicate provider and
recipient preferences for specific features.
o 交渉は特定の特徴のためにプロバイダーと受取人好みを示す方法を提供するべきです。
o Negotiation should have the minimum possible impact on network
resource consumption, particularly in terms of bandwidth and
number of protocol round-trips required.
o 交渉は最小の可能な影響力をネットワーク資源消費に持つべきです、特に周遊旅行が必要としたプロトコルの帯域幅と数に関して。
o Systems should protect the privacy of users' profiles and
providers' inventories of variants.
o システムはユーザのプロフィールのプライバシーとプロバイダーの異形の目録を保護するはずです。
o Protocol specifications should identify and permit mechanisms to
verify the reasonable accuracy of any capability data provided.
o どんな能力データの妥当な精度についても確かめる仕様が特定するべきであるプロトコルと許可証メカニズムは提供されました。
o Negotiation must not significantly jeopardize the overall
operation or integrity of any system in the face of erroneous
capability data, whether accidentally or maliciously provided.
o 交渉は誤った能力データに直面してどんなシステムの総合的な操作か保全もかなり危険にさらしてはいけません、偶然か陰湿に提供するか否かに関係なく。
o Intelligent gateways, proxies, or caches should be allowed to
participate in the negotiation.
o 知的なゲートウェイ、プロキシ、またはキャッシュが交渉に参加できるべきです。
o Negotiation metadata should be regarded as cacheable, and explicit
cache control mechanisms provided to forestall the introduction of
ad-hoc cache-busting techniques.
o 「キャッシュ-可能」であって、明白なキャッシュ制御機構が臨時のキャッシュを破産させたテクニックの導入を出し抜くために提供されたので、交渉メタデータは見なされるべきです。
Klyne Informational [Page 13] RFC 2703 Protocol-independent Content Negotiation September 1999
2703年の[13ページ]RFCのプロトコルから独立している内容交渉1999年9月の情報のKlyne
o Automatic negotiation should not pre-empt a user's ability to
choose a document format from those available.
o 自動交渉は利用可能なそれらからドキュメント・フォーマットを選ぶユーザの能力を先取りするべきではありません。
5. Technical issues
5. 専門的な問題
5.1 Non-message resource transfers
5.1 非メッセージ資源移転
The ideas for generic content negotiation have been conceived and developed in the context of message-oriented data transmissions.
メッセージ指向のデータ伝送の文脈でジェネリック内容交渉のための考えを、発想されて、開発してあります。
Message data is defined elsewhere as a data whose entire content is decided before the start of data transmission. The following are examples of non-message data transfers.
メッセージデータはほかの場所で全体の内容がデータ伝送の始まりの前に決められるデータと定義されます。 ↓これは非メッセージデータ転送に関する例です。
o streamed data,
o データを流しました。
o interactive computations,
o 対話的な計算
o real-time data acquisition,
o リアルタイムデータ獲得
Does a proposed approach to negotiation based on message data reasonably extend to streamed data (e.g. data whose content is not fully determined by the time the first data items are transmitted)?
合理的にメッセージデータに基づく交渉への提案されたアプローチは流されたデータ(例えば、最初のデータ項目が伝えられる時までに内容が完全に決定するというわけではないデータ)に達しますか?
It may be that the metadata will be applicable, but the abstract negotiation process framework may be insufficient to these more demanding circumstances.
多分、メタデータは適切になるでしょうが、抽象的な交渉プロセスフレームワークはこれらのより過酷な事情に不十分であるかもしれません。
5.2 End-to-end vs hop-by-hop negotiations
5.2終わりから終わり対ホップごとの交渉
Could this distinction place any special demands or constraints on a generic negotiation framework, or is this simply a protocol issue?
この区別が何か特別な要求や規制をジェネリック交渉フレームワークに置くかもしれませんか、またはこれは単にプロトコル問題ですか?
o End-to-end negotiation gives greatest confidence in the outcome.
o 終わりから終わりとの交渉は結果で最もすごい信用を与えます。
o Hop-by-hop may have advantages in a network of occasionally-
connected systems, but will place additional demands on
intervening message transmission agents.
o 時折接続されたシステムのネットワークにおいてうま味があるかもしれませんが、ホップごとに、介入しているメッセージトランスミッションエージェントに追加需要を置くでしょう。
Hop-by-hop negotiation implies that negotiation responses are not necessarily a definitive indication of an endpoint system's capabilities. This in turn implies a possible need for time-to-live and re-verification mechanisms to flush out stale negotiation data.
ホップごとの交渉は、交渉応答が必ず終点システムの能力の決定的なしるしであるというわけではないことを含意します。 これは順番に生きる時間と再検証メカニズムが聞き古した交渉データを洗う可能な必要性を含意します。
Note that one of the stated goals is to allow proxies and caches to participate in the negotiation process, as appropriate.
述べられた目標の1つがプロキシとキャッシュが交渉プロセスに参加するのを許容することであることに注意してください、適宜。
Klyne Informational [Page 14] RFC 2703 Protocol-independent Content Negotiation September 1999
2703年の[14ページ]RFCのプロトコルから独立している内容交渉1999年9月の情報のKlyne
5.3 Third-party negotiation
5.3 第三者交渉
An extension of the hop-by-hop vs. end-to-end negotiation theme is to consider the implications of allowing any system other than an endpoint participant in the message transmission to supply negotiation metadata.
ホップ対終わりから終わりとの交渉ごとのテーマの拡大はメッセージ送信の終点関係者以外のどんなシステムも交渉メタデータを提供するのを許容する含意を考えることです。
Any use of a third party in the negotiation process inevitably increases the possibilities for introducing errors into the negotiation metadata.
交渉プロセスにおける第三者のどんな使用も、交渉メタデータに誤りを取り入れるために必然的に可能性を増強します。
One particular example of a third party participant in a negotiation process that is frequently suggested is the use of a directory service using LDAP or similar protocols. What additional steps need to be taken to ensure reasonable reliability of negotiation metadata supplied by this means?
頻繁に示される交渉プロセスの第三者関係者の1つの特定の例はLDAPを使用するディレクトリサービスか同様のプロトコルの使用です。 どんな追加ステップが、このようにして提供された交渉メタデータの妥当な信頼性を確実にするために取られる必要がありますか?
5.4 Use of generic directory and resolution services
5.4 ジェネリックディレクトリと解決サービスの使用
It is clearly helpful to use existing protocols such as LDAP to exchange content negotiation metadata.
満足している交渉メタデータを交換するのにLDAPなどの既存のプロトコルを使用するのは明確に役立っています。
To achieve this, it be necessary to define directory or other schema elements which are specific to content negotiation. For example, an LDAP attribute type for a media feature set.
これを達成するために、ディレクトリか他の満足している交渉に特定の図式要素を定義するのが必要です。 例えば、メディア機能のためのLDAP属性タイプはセットしました。
5.5 Billing issues
5.5 支払い問題
Negotiation may raise some billing-related issues in some contexts because it potentially incurs a two-way exchange of data not necessarily completed during a single connection. There is an issue of who pays for return messages, etc., in a non-connected environment like e-mail or fax.
潜在的に必ず単独結合の間に完成したというわけではないデータの双方からの交流を被るので、交渉はいくつかの文脈のいくつかの支払い関連の問題を提起するかもしれません。 メールやファックスのような非関連している環境にはだれがリターンメッセージなどの代価を払うかに関する問題があります。
5.6 Performance considerations
5.6 パフォーマンス問題
Negotiation can impact performance in both positive and negative ways.
交渉は積極的なものに同様に負の方法で性能に影響を与えることができます。
The obvious negative impact arises from the exchange of additional data which necessarily consumes some additional bandwidth. There is also an issue of round-trip or third-party query delays while negotiation metadata is being exchanged before transmission of the message itself is commenced.
明白な負の衝撃は必ずいくらかの追加帯域幅を消費する追加データの交換から起こります。 また、往復か第三者質問遅れの問題がメッセージ自体の伝達を始める前に交渉メタデータを交換している間、あります。
Over the Internet, there are some bandwidth/latency trade-offs which can be made. For example, in Internet e-mail the MIME type ' multipart/alternative' can be used to send multiple versions of a
インターネットの上に、することができるいくつかの帯域幅/潜在トレードオフがあります。 例えば、インターネット電子メールでは、aの複数のバージョンを送るのにMIMEの種類'複合/代替手段'を使用できます。
Klyne Informational [Page 15] RFC 2703 Protocol-independent Content Negotiation September 1999
2703年の[15ページ]RFCのプロトコルから独立している内容交渉1999年9月の情報のKlyne
resource: this preserves latency by using additional bandwidth to send a greater volume of data. On the other hand, HTTP [7] suggests a negotiation mechanism which preserves bandwidth at the cost of introducing a round-trip delay (section 12.2, Agent-driven negotiation).
リソース: これは、よりすばらしいデータ量を送るのに追加帯域幅を使用することによって、潜在を保持します。 他方では、HTTP[7]は往復の遅れ(セクション12.2、エージェント駆動の交渉)を導入する費用で帯域幅を保持する交渉メカニズムを示します。
To set against the negative performance impact of content negotiation, it is to be hoped that overall network efficiency is to be improved if it results in the most useful data format being delivered to its intended recipient, first time, almost every time.
願わくは総合的なネットワーク効率は満足している交渉の否定的性能影響に対してセットするためには、意図している受取人に提供される中で最も役に立つデータの形式をもたらすなら改良されていることです、初めてです、ほとんど毎回。
5.7 Confidence levels in negotiated options
5.7 交渉されたオプションにおける信用レベル
In some cases (e.g. when there has been a direct exchange of information with the remote system) the communicating parties will have a high degree of confidence in the outcome of a negotiation. Here, a data exchange can be performed without need for subsequent confirmation that the options used were acceptable.
いくつかの場合(例えば、いつ、リモートシステムによる情報の直接交換がありましたか)、交信パーティーには、交渉の結果における、高度合いの信用があるでしょう。 ここで、オプションが使用したその後の確認が許容できるので、データは交換を実行できるそうしなければなりません。
In other cases, the options will be a best-guess, and it may be necessary to make provision for parties to reject the options actually used in preference for some other set.
他の場合では、オプションは最も良い推測でしょう、そして、ある他のセットに実際に好みに使用されるオプションを拒絶するためにパーティーに備えるのが必要であるかもしれません。
This consideration is likely to interact with performance considerations.
この考慮は性能問題と対話しそうです。
A useful pattern, adopted by TCN [5], is to define a negotiation procedure which guarantees a correct outcome. This forms the foundation for a procedure which attempts to use easily-obtained but less reliable information in an attempt to optimize the negotiation process but that contains checks to guarantee the final result will be the same as would have been obtained by the full negotiation procedure. Such procedures sometimes have to resort to the original "full cycle" negotiation procedure, but in a majority of cases are expected to reach their conclusion by an optimized route.
TCN[5]によって採用された役に立つパターンは正しい結果を保証する交渉手順を定義することです。 これは使用への試みが容易に得た手順の基礎を形成しますが、完全な交渉手順で交渉プロセスを最適化する同じであることを最終的な結果がなる保証するチェックを含む試みにおける、より少ない信頼できる情報を得たでしょう。 そのような手順は、時々元の「完全なサイクル」交渉手順に訴えなければなりませんが、最適化されたルートで彼らの結論に達すると多くの場合予想されます。
6. Security Considerations
6. セキュリティ問題
The purposes of this section is to identify and catalogue some security issues that feature negotiation protocols should consider.
このセクションの目的は、特徴交渉プロトコルが考えるべきであるいくつかの安全保障問題を特定して、カタログに載せることです。
6.1 Privacy
6.1 プライバシー
Privacy may be adversely affected by:
プライバシーは以下で悪影響を受けるかもしれません。
o Unintended disclosure of personal information.
o 個人情報の故意でない公開。
Klyne Informational [Page 16] RFC 2703 Protocol-independent Content Negotiation September 1999
2703年の[16ページ]RFCのプロトコルから独立している内容交渉1999年9月の情報のKlyne
o Spoofed requests for negotiation data simply for the purposes of
gathering information, and not as part of a bona fide message
transmission.
o 単に誠実なメッセージ送信の一部ではなく、集会情報の目的のための交渉データに関する要求であると偽造されます。
6.2 Denial of service attacks
6.2 サービス攻撃の否定
Service denial may be caused by:
サービス否定は以下によって引き起こされるかもしれません。
o Injection of false negotiation data.
o 誤った交渉データの注射。
o Excessive requests for negotiation data
o 交渉データに関する過度の要求
6.3 Mailing list interactions
6.3 メーリングリスト相互作用
Content negotiation with final recipients is somewhat at odds with normal practice for maintaining lists for redistribution of Internet mail.
最終的な受取人との満足している交渉がいくらかインターネット・メールの再分配のためのリストを維持するための正常な習慣と仲たがいしてあります。
It may be appropriate for a sender to negotiate data formats with a list manager, and for a list manager to negotiate with message recipients. But the common practice of keeping confidential the identities and addresses of mailing list subscribers suggests that end-to-end negotiation through a mailing list is not consistent with good security practice.
送付者がデータ形式をリストマネージャと交渉して、リストマネージャがメッセージ受取人と交渉するのは、適切であるかもしれません。 しかし、メーリングリスト加入者のアイデンティティとアドレスを秘密にする一般的な習慣は、終わりから終わりとのメーリングリストを通した交渉が優れた警備体制習慣と一致していないと示唆します。
6.4 Use of security services
6.4 セキュリティー・サービスの使用
Protocols that employ security services for message transfer should also apply those services to content negotiation:
また、メッセージのための雇用セキュリティー・サービスが移すプロトコルはそれらのサービスを満足している交渉に適用するべきです:
o Authenticated requests for negotiation metadata provide a means
for a potential recipient to moderate the distribution of media
capability information.
o 交渉メタデータに関する認証された要求は潜在的受取人がメディア能力情報の分配を加減する手段を提供します。
o Authentication of negotiation metadata provides a means for
potential message senders to avoid using incorrect information
injected by some other party.
o 交渉メタデータの認証は潜在的メッセージ送付者がある他のパーティーによって注入された不正確な情報を使用するのを避ける手段を提供します。
o Encryption of negotiation data may help to prevent disclosure of
sensitive capability-related information to snoopers.
o 交渉データの暗号化は、機密の能力関連の情報の公開を詮索好きに防ぐのを助けるかもしれません。
o Conducting a negotiation exchange over an authenticated or
encrypted protocol session (e.g. SASL), transport connection or
network path (e.g. TLS, IPSEC) can provide for mutual
authentication of both parties in an exchange of negotiation data.
o 認証されたか暗号化されたプロトコルセッション(例えば、SASL)、輸送接続またはネットワーク経路(例えば、TLS、IPSEC)の上の交渉交換を行うと、交渉データの交換における、双方の互いの認証に備えることができます。
Klyne Informational [Page 17] RFC 2703 Protocol-independent Content Negotiation September 1999
2703年の[17ページ]RFCのプロトコルから独立している内容交渉1999年9月の情報のKlyne
6.5 Disclosure of security weaknesses
6.5 セキュリティ弱点の公開
6.5.1 User agent identification
6.5.1 ユーザエージェント識別
Disclosure of capability information may allow a potential attacker to deduce what message handling agent is used, and hence may lead to the exploitation of known security weaknesses in that agent.
能力情報の公開は、潜在的攻撃者が、メッセージハンドリングエージェントが者であると使用されていた状態で推論するのを許容して、したがって、そのエージェントで知られているセキュリティ弱点の攻略につながるかもしれません。
6.5.2 Macro viruses
6.5.2 マクロウイルス
Macro viruses are a widespread problem among applications such as word processors and spreadsheets. Knowing which applications a recipient employs (e.g. by file format) may assist in a malicious attack. However, such viruses can be spread easily without such knowledge by sending multiple messages, where each message infects a specific application version.
マクロウイルスはワードプロセッサやスプレッドシートなどのアプリケーションの中の広範囲の問題です。 受取人がどのアプリケーションを使うかを(例えば、ファイル形式で)知っているのが悪意ある攻撃を助けるかもしれません。 しかしながら、そのような知識なしで複数のメッセージを送ることによって、そのようなウイルスを容易に広げることができます。(そこでは、各メッセージが特定のアプリケーションバージョンを感染させます)。
6.5.3 Personal vulnerability
6.5.3 個人的な脆弱性
One application of content negotiation is to enable the delivery of message content that meets specific requirements of less able people. Disclosure of this information may make such people potential targets for attacks that play on their personal vulnerabilities.
満足している交渉の1つの応用はそれほど有能でない人々の決められた一定の要求を満たすメッセージ内容の配送を可能にすることです。 この情報の公開はそれらの個人的な脆弱性でプレーする攻撃のためのそのような人々仮想ターゲットを作るかもしれません。
6.6 Problems of negotiating security
6.6 セキュリティを交渉するという問題
If feature negotiation is used to decide upon security-related features to be used, some special problems may be created if the negotiation procedure can be subverted to prevent the selection of effective security procedures.
特徴交渉が使用されるべきセキュリティ関連の特徴について決めるのに使用されるなら、効果的なセキュリティ手順の品揃えを防ぐために交渉手順を打倒できるなら、いくつかの特別な問題が生じるかもしれません。
The security considerations section of GSS-API negotiation [8] discusses the use of integrity protecting mechanisms with security negotiation.
GSS-API交渉[8]のセキュリティ問題部はセキュリティ交渉でメカニズムを保護する保全の使用について論じます。
7. Acknowledgements
7. 承認
Some material in this memo has been derived from earlier memos by Koen Holtman, Andrew Mutz, Ted Hardie, Larry Masinter, Dan Wing, Neil Joffe. Matters relating to the importance and relevance of content negotiation to less-able users were raised by Al Gilman.
クンHoltmanによる以前のメモからこのメモによる何らかの材料を得ました、アンドリューMutz、テッド・ハーディー、ラリーMasinter、ダンWing、ニール・ジョフィ。 満足している交渉の重要性と関連性をより少ないできるユーザと関係がある件がアル・ギルマンによって提起されました。
This memo has also been informed by the debates of the IETF "conneg" working group.
また、このメモはIETF"conneg"ワーキンググループの討論で知らされました。
Klyne Informational [Page 18] RFC 2703 Protocol-independent Content Negotiation September 1999
2703年の[18ページ]RFCのプロトコルから独立している内容交渉1999年9月の情報のKlyne
8. References
8. 参照
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part 1: Format of Internet message bodies",
RFC 2045, November 1996.
解放された[1]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)第1部:」 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part 2: Media Types", RFC 2046, November 1996.
解放された[2]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)第2部:」 「メディアタイプ」、RFC2046、1996年11月。
[3] Holtman, K., et al., "The Alternates Header Field", Work in
Progress.
[3]Holtman、K.、他、「補欠ヘッダーフィールド」、ProgressのWork。
[4] Hardie, T., "Scenarios for the Delivery of Negotiated Content",
Work in Progress.
[4] ハーディー、T.、「交渉された内容の配送のためのシナリオ」が進行中で働いています。
[5] Holtman, K. and A. Mutz, "Transparent Content Negotiation in
HTTP", RFC 2295, March 1998.
[5]HoltmanとK.とA.Mutz、「HTTPにおけるわかりやすい満足している交渉」、RFC2295、1998年3月。
[6] Wing, D., "Indicating Supported Media Features Using Extensions
to DSN and MDN", RFC 2530, March 1999.
[6] 翼、D.、「表示は、メディアが特徴であるとDSNとMDNに拡張子を使用することでサポートした」RFC2530、1999年3月。
[7] Fielding, R., Gettys, J., Mogul, J., Frytyk, H. and T. Berners-
Lee, "Hyptertext Transfer Protocol -- HTTP/1.1", RFC 2068,
January 1997.
[7]フィールディング、R.、Gettys、J.、ムガール人、J.、Frytyk、H.、およびT.Bernersリー、「Hyptertextはプロトコルを何HTTP/1.1インチも移します、RFC2068、1997年1月。」
[8] Blaize, E. and D. Pinkas, "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, December 1998.
E.とD.ピンカス、「簡単で保護されたGSS-API交渉メカニズム」RFC2478、[8]はBlaizeして、12月は1998です。
9. Author's Address
9. 作者のアドレス
Graham Klyne 5th Generation Messaging Ltd. Content Technologies Ltd. 5 Watlington Street 1220 Parkview, Arlington Business Park Nettlebed Theale Henley-on-Thames, RG9 5AB Reading, RG7 4SA United Kingdom United Kingdom.
グラハムKlyne第5世代メッセージング株式会社コンテンツ技術株式会社5ウォトリントン通り1220Parkview、アーリントンビジネスはNettlebed Thealeヘンリーオンテムズ、RG9 5AB読書、RG7 4SAイギリスのイギリスを駐車します。
Phone: +44 1491 641 641 +44 118 930 1300 Fax: +44 1491 641 611 +44 118 930 1301 EMail: GK@ACM.ORG
以下に電話をしてください。 +44 1491 641 641+44 118 930、1300Fax: +44 1491 1301年の641 611+44 118 930メール: GK@ACM.ORG
Klyne Informational [Page 19] RFC 2703 Protocol-independent Content Negotiation September 1999
2703年の[19ページ]RFCのプロトコルから独立している内容交渉1999年9月の情報のKlyne
10. Full Copyright Statement
10. 完全な著作権宣言文
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Klyne Informational [Page 20]
Klyne情報です。[20ページ]
一覧
スポンサーリンク
