Network Working Group G. Klyne
Request for Comments: 2703 5GM/Content Technologies
Category: Informational September 1999
Protocol-independent Content Negotiation Framework
Status of this 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.
著作権（C）インターネット協会（1999）。全著作権所有。
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]変化の主軸を処理するための標準的な方法を提供するが、リソースは、現在利用可能な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
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
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.
フレームワークがかかる場合がありますフォームのいずれかの仮定を避けるためにしようとしているときに目標の文は、コンテンツネゴシエーションフレームワークの所望の特性を設定することを意図しています。
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節では、適切な他の作業への相互参照して、本文書によって提起されている技術的な問題のいくつかを説明します。
Discussion of this document should take place on the content negotiation and media feature registration mailing list hosted by the Internet Mail Consortium (IMC).
本書の議論は、インターネットメールコンソーシアム（IMC）によってホストされているコンテンツのネゴシエーションとメディア特徴登録メーリングリストで行われるべき。
Please send comments regarding this document to:
このドキュメントに関するコメントを送ってください。
ietf-medfree@imc.org
いえｔｆーめｄｆれえ＠いｍｃ。おｒｇ
To subscribe to this list, send a message with the body 'subscribe' to "ietf-medfree-request@imc.org".
このリストを購読するには、「ietf-medfree-request@imc.org」に「購読の体にメッセージを送信します。
To see what has gone on before you subscribed, please see the mailing list archive at:
あなたが加入する前に行っているかを確認するには、でメーリングリストのアーカイブを参照してください。
http://www.imc.org/ietf-medfree/
ｈっｔｐ：／／ｗっｗ。いｍｃ。おｒｇ／いえｔｆーめｄｆれえ／
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.
能力生成またはメッセージコンテンツの特定のタイプを処理する能力を示す送信側または受信側（しばしば受信機）の属性。
Characteristic Some description of a sender or receiver which indicates a possible capability or preference.
可能な能力または嗜好を示す送信者または受信機の特性のいくつかの説明。
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.
Choiceのメッセージは選択メッセージが一緒に交渉リソースのバリアントリストと、いくつかの選択された変異体または変異型の表現を返します。これは、送信者が受信者のためのバリアントを選択するのに十分な情報を持っており、また、利用可能な他の亜種についての受信機に通知するために必要とするときに生成することができます。
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)
したがって、接続モード送信側と受信側とが直接接続されている動作モードとは決定的に互いの能力を決定することが防止されていません。 （参照：セッションモード）
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.
コンテントネゴシエーションデータリソースを転送するときに適切な表現（バリアント）の選択につながる情報の交換（交渉メタデータ）。
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)
データを転送することができるネットワーク・データ・オブジェクトをリソース。データリソースは複数の表現（例えば、複数の言語、データフォーマット、サイズ、解像度）で利用可能であるか、または他の方法で変えることができます。 （参照：メッセージ、リソース）
Feature A piece of information about the media handling properties of a message passing system component or of a data resource.
メッセージパッシングシステムコンポーネントまたはデータ・リソースのメディア処理特性に関する情報の一部を備えています。
Feature tag A name that identifies a "feature".
特集は「機能」を識別する名前をタグ付けします。
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.
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.
一覧メッセージリストメッセージは、ネゴシエート可能なリソースのバリアントリストを送信し、ないバリアントデータ。これは、送信者はしたくないときに発生することができ、または、特定の変異体を送信することが許可されていません。
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.
一緒に適用することができる任意のカプセル化と、受信機に送信機から送信されるメッセージデータ。データリソースは、表現の数が利用可能なものが、元のデータである場合、メッセージが実際に送信されるこれらの表現（S）を含有します。交渉メタデータは、一般的に、メッセージの一部とは見なされません。
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.
コンテンツネゴシエーションにより選択された交渉されたコンテンツメッセージの内容。
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.
ネゴシエート可能なリソース、それに関連付けられた複数の表現（バリアント）を有するデータリソース。メッセージの送信のための適切な変異体の選択は、送信者と受信者との間のコンテンツネゴシエーションすることによって達成されます。
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 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.
嗜好の両方が可能であっても、生成するか、または別の上にメッセージコンテンツの特定のタイプを処理する優先度を示す送信側または受信側（しばしば受信機）の属性。
Receiver A system component (device or program) which receives a message.
メッセージを受信したシステム構成要素（装置又はプログラム）受信機。
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.
受信機が開始した送信メッセージの最終的な受信者によって要求されたメッセージの送信。時には「プル」のメッセージとして記述。例えば。 HTTPのGET操作。
Resource A document, data file or facility which is accessed or transmitted across a network. (See also: Data resource)
アクセスまたはネットワークを介して送信された文書、データファイルや施設リソース。 （参照：データリソース）
Sender A system component (device or program) which transmits a message.
メッセージを送信する送信側システムコンポーネント（デバイスまたはプログラム）。
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.
送信者が開始した送信メッセージの送信者によって起動されるメッセージの送信。時には「プッシュ」のメッセージとして記述。例えば。電子メールを送信します。
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)
セッションモードメッセージ配信の確認メッセージを送信するために使用される同じアプリケーション・セッション（通常同じトランスポート接続）に送信者によって受信されたメッセージの送信のモード。 （参照：接続モード、ストアアンドフォワードモード）
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.
保存および回送モードメッセージが配信される前に、メッセージ転送エージェントの時間の未知の期間のために記憶装置に保持されているメッセージの送信のモード。
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.)
いくつかの値を表現するために使用されるフォームを構文。特にメディア特徴量を表現するために使用される形式、または機能セット。 （参照：特徴量、機能セット、タイプを。）
Transmission The process of transferring a message from a sender to a receiver. This may include content negotiation.
送信受信機に送信者からのメッセージを転送するプロセス。これは、コンテンツネゴシエーションを含んでいてもよいです。
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.
User agent A system component which prepares and transmits a message, or receives a message and displays, prints or otherwise processes its contents.
ユーザエージェントは、そうでなければ作成し、メッセージを送信、またはメッセージやディスプレイ、プリントを受け取るまたはシステムコンポーネントがその内容を処理します。
Variant One of several possible representations of a data resource.
バリアントデータリソースのいくつかの可能な表現の一つ。
Variant list A list containing variant descriptions, which can be bound to a negotiable resource.
バリアントは交渉のリソースにバインドすることができバリアントの記述を含むリストを一覧表示します。
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.
バリアント説明通常、バリアントリストで見つかったバリアントリソースの機械可読説明。変異体の説明は、バリアントリソース識別子及び変異体の特性を記述する各種の属性を含みます。
Variant resource A data resource for which multiple representations (variants) are available.
バリアントリソース複数の表現（バリアント）が利用可能であるデータリソース。
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.
このドキュメントの目的のために、メッセージ伝送プロトコル機能は、明示的に無視されていますが、これらは、いくつかの直交メカニズムによって別個に扱われることが推測されます。
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（メッセージの送信に先立って）受信機の機能を発現する、および
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 ]
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.
アプリケーションプロトコルの独立性は、具体的な表現とプロトコルバインディングから抽象交渉プロセスとメタデータを分離することによって対処されます。
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つの主要な要素があります。
The life of a data resource may be viewed as:
データリソースの生活はと見ることができます。
(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] =文書（C）=原稿内容[S] =メッセージ（F）[R]（（C）の表現）システム（T）=送信されたデータファイルを送信=受信システム=フォーマット（レンダリングされた）文書の作者文書のデータ（プレゼンテーションの（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.
ここでは、[S]で、[R]（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]と同様に処理し、受信したデータをレンダリングする独自の能力のニーズや好みを考慮に入れるであろう。
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:
例えば、透過的内容ネゴシエーション（TCN）[5]次のいずれかが発生したモデルを使用しています。
o The recipient requests a resource with no variants, in which case the sender simply sends what is available.
O受信者は送信者は、単に利用可能なもの送信する場合にはいない変異体でリソースを要求します。
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バリアントリソースは、サーバーが利用できるバリアントのリストで応答し、そして、クライアントが提供されたものの中から一つの変形を選択した場合には、要求されています。
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「マルチパート/代替」の使用に関して行うことができます。
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機能セット：することができる可能なメディア機能の組み合わせの範囲の説明：送信者によって提供されます。データファイル形式によって表されます。または受信機によって処理されます。
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。これらは、名前の一意性を確保し、一般的に使用される機能のための共通の語彙を奨励するために、登録プロセスのいくつかの種類によってバックアップする必要があります。
o A framework of data types for media features, indicating the range and properties of value types which can be represented.
メディア機能のためのデータ・タイプのフレームワークO、表すことができる値の種類の範囲及び性質を示しています。
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).
機能セット（例えば640×480画素サイズと256色、または800×600画素サイズと16色）内の機能の依存関係を表現することが可能な機能セット、にメディア機能を組み合わせるO方法。
o Some way to rank feature sets based upon sender and receiver preferences for different feature values.
Oいくつかの方法が異なる特徴値のために送信者と受信者の好みに基づいた機能セットをランク付けします。
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.
交渉メタデータのテキスト表現は、メディア機能名の、とも代数を組み合わせたメディア機能の表現のためのテキスト表現を暗示します。
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.
非テキストベースのプロトコルで使用する場合は、交渉メタデータのためのASN.1記述とエンコーディングの指定はX.400、X.500、LDAPおよびSNMPなどの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オブジェクト識別子に基づいて、独立したメディア機能の命名方式は有益であろうことを示唆しています。
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は、ここで有用なモデルを提供するかもしれません。）
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.
特定のプロトコル（例えば、HTTPプロトコルの動作に関連し、キャッシュ相互作用、セキュリティ上の問題、既存のHTTPネゴシエーションメカニズム、バリアント選択のアプリケーション、等）の文脈における交渉の展開に関係2.具体的な目標。これらは、交渉の枠組みのための結合特定のプロトコルによって対処されるだろう。
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少ないことがコンピュータユーザーの通信ニーズを満たすのコンテンツネゴシエーションの役割に対処できること。
o A negotiation should generally result in identification of a mutually acceptable form of message data to be transferred.
Oネゴシエーションは、一般的に転送されるメッセージデータの相互に許容可能な形の識別をもたらすはずです。
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ネゴシエーションメタデータはキャッシュ可能とみなし、明示的なキャッシュ制御メカニズムは、アドホックキャッシュ無効化技術の導入を未然に防ぐために提供されるべきです。
o Automatic negotiation should not pre-empt a user's ability to choose a document format from those available.
O自動ネゴシエーションはいけません利用可能なものから文書フォーマットを選択するユーザの能力を横取り。
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.
これは、メタデータが適用されますことかもしれないが、抽象的交渉プロセスフレームワークは、これらのより厳しい状況には不十分です。
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.
述べた目標の一つは、プロキシやキャッシュが必要に応じて、交渉プロセスに参加できるようにすることであることに注意してください。
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または同様のプロトコルを使用してディレクトリ・サービスを使用することです。どのような追加の手順は、この手段により供給された交渉メタデータの合理的な信頼性を確保するために取られる必要がありますか？
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は、メディア機能セットのための属性タイプ。
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.
それは潜在的に必ずしも単一の接続中に完了していないデータの双方向交換を負うため、交渉は、いくつかの状況では、いくつかの課金関連の問題を引き起こす可能性があります。電子メールやファックスなどの非接続環境では、などのリターンメッセージ、のために支払うだれの問題があります。
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 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).
インターネット上で、行うことができるいくつかの帯域幅/レイテンシのトレードオフがあります。例えば、インターネット電子メールでMIMEタイプ「マルチパート/代替」はリソースの複数のバージョンを送信するために使用することができる。これは、データのより大きな量を送信するために追加の帯域幅を使用して待ち時間を保存します。一方、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.
コンテンツネゴシエーションの負のパフォーマンスへの影響に対して設定するには、ネットワーク全体の効率は、その意図された受信者、初めて、ほぼすべての時間に配信される最も有用なデータ形式になる場合に改善されることが期待されます。
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]、正確な結果を保証する交渉手順を定義することです。これは、交渉プロセスを最適化する試みで、容易に得られたが、あまり信頼できる情報を使用しようとする手順の基礎を形成するが、それは完全なネゴシエーション手順によって得られたであろうと同じになり、最終的な結果を保証するためにチェックが入っています。このような手順は、時々、元の「フルサイクル」交渉手続きに頼る必要がありますが、ほとんどの場合に最適化された経路でその結論に達すると予想されています。
The purposes of this section is to identify and catalogue some security issues that feature negotiation protocols should consider.
このセクションの目的は、プロトコルが検討すべき交渉を備えていますいくつかのセキュリティ上の問題を特定し、カタログすることです。
Privacy may be adversely affected by:
プライバシーに悪影響によって影響を受ける可能性があります
o Unintended disclosure of personal information.
個人情報のO意図しない開示。
o Spoofed requests for negotiation data simply for the purposes of gathering information, and not as part of a bona fide message transmission.
O単に情報を収集する目的ではなく、真正なメッセージ送信の一部としてネゴシエーションデータの要求をスプーフィング。
Service denial may be caused by:
サービス拒否はによって引き起こされることがあります。
o Injection of false negotiation data.
偽のネゴシエーションデータの入出力注入。
o Excessive requests for negotiation data
ネゴシエーションデータ用O過度の要求
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.
これは、送信者がリストマネージャとデータ・フォーマットを交渉するために適切であり得る、およびリストマネージャのメッセージの受信者と交渉します。しかし、メーリングリストの加入者のアイデンティティとアドレスを機密保持する一般的な方法は、メーリングリストを通じて、エンドツーエンドの交渉が優れたセキュリティ慣行と一致していないことを示唆しています。
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 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.
認証または暗号化プロトコルセッション（例えばSASL）上ネゴシエーション交換を実施O、トランスポート接続またはネットワーク・パス（例えばTLS、IPSEC）は、ネゴシエーションデータの交換における両当事者の相互認証を提供することができます。
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.
能力情報の開示は、潜在的な攻撃者が取り扱い剤を使用するメッセージの内容を推測するために、ひいてはそのエージェントの既知のセキュリティ上の弱点の搾取につながる可能性があります。
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.
マクロウイルスは、このようなワードプロセッサやスプレッドシートなどのアプリケーションの間で広まっ問題です。受信者は、（例えばファイルフォーマットで）採用アプリケーションを知ることは、悪意のある攻撃を助けることができます。しかしながら、このようなウイルスは、各メッセージは、特定のアプリケーションのバージョンに感染する複数のメッセージを送信することによって、そのような知識がなくても容易に広げることができます。
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つの用途は少ないことができ、人々の特定の要件を満たしているメッセージのコンテンツの配信を可能にするためです。この情報の開示は、彼らの個人的な脆弱性で再生攻撃のためのそのような人々の潜在的なターゲットを行うことができます。
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]セキュリティネゴシエーションとメカニズムを完全性保護の使用について説明します。
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、ダン・ウィング、ニール・ジョフィにより、以前のメモから導出されています。少ない可能なユーザにコンテンツネゴシエーションの重要性と妥当性に関する事項は、アルギルマンによって提起されました。
This memo has also been informed by the debates of the IETF "conneg" working group.
また、このメモはIETF「conneg」ワーキンググループの議論によって通知されました。
[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：インターネットメッセージ本体のフォーマット"、RFC 2045、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：メディアタイプ"、RFC 2046、1996年11月。
[3] Holtman, K., et al., "The Alternates Header Field", Work in Progress.
[3] Holtman、K.、ら。、 "のAlternatesヘッダーフィールド"、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における透明コンテントネゴシエーション"、RFC 2295、1998年3月。
[6] Wing, D., "Indicating Supported Media Features Using Extensions to DSN and MDN", RFC 2530, March 1999.
[6]ウイング、D.、RFC 2530、1999年3月 "サポートされているメディアを示すには、DSNとMDNに拡張機能を使用しています"。
[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.、ゲティス、J.、モーグル、J.、Frytyk、H.、およびT.バーナーズ - リー、 "Hyptertext転送プロトコル - HTTP / 1.1"、RFC 2068、1997年1月。
[8] Blaize, E. and D. Pinkas, "The Simple and Protected GSS-API Negotiation Mechanism", RFC 2478, December 1998.
[8]ブレイズ、E.およびD.ピンカス、 "単純で保護されたGSS-API交渉メカニズム"、RFC 2478、1998年12月。
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ワトリントンストリート1220パークビュー、アーリントンビジネスパーク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 1300ファックス：+44 1491 641 611 +44 118 930 1301 Eメール：GK@ACM.ORG
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。