[要約] RFC 2703は、プロトコルに依存しないコンテンツネゴシエーションフレームワークに関する要約と目的を提供しています。このRFCの目的は、異なるプロトコル間でのコンテンツの適切な選択と交換を容易にすることです。
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.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
Abstract
概要
A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact. 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
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
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/
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.
選択メッセージの選択メッセージは、交渉可能なリソースのバリアントリストとともに、選択したバリアントまたはバリアントの表現を返します。送信者がレシーバーのバリアントを選択するのに十分な情報を持っている場合、および利用可能な他のバリアントについてレシーバーに通知する必要がある場合に生成できます。
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.
送信者から受信機に送信されるメッセージデータと、適用される可能性のあるカプセル化とともに。データリソースが多くの表現で利用可能な元のデータである場合、メッセージには実際に送信される表現が含まれています。ネゴシエーションメタデータは、一般にメッセージの一部とは見なされません。
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.
注：これは、「属性タイプ」という用語を使用してディレクトリエントリの値の識別子を記述する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.
ユーザーエージェントメッセージを準備および送信するシステムコンポーネント、またはメッセージを受信し、そのコンテンツを表示、印刷、または処理します。
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.
バリアントリスト交渉可能なリソースにバインドできるバリアントの説明を含むリスト。
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. レシーバーの機能を表現する（メッセージの送信前）、および
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 ]
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]
（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
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.
ここでは、交渉メタデータを交換して（t）の形式を決定するのは[s]と[r]です。したがって、これらの要素は私たちの注意の焦点です。
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 バリアントリソースが要求されます。その場合、サーバーは利用可能なバリアントのリストで返信し、クライアントは提供されたバリアントから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.
もう1つの簡単な例は、FAXの交渉の例です。この場合、意図した受信者はその機能を宣言し、送信者は一致するメッセージバリアントを選択します。
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/Alternative」の使用に関する電子メールメッセージ送信に関する同様の観察結果を作成できます。
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 メディア機能と機能セットにラベルを付けるための1つ以上の命名スキーム。これらは、名前の一意性を確保し、一般的に使用される機能の共通の語彙を奨励するために、何らかの登録プロセスによってバックアップする必要があります。
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).
o メディア機能を機能セットに組み合わせて、機能セット内で機能依存関係を表現できます（例：640x480ピクセルサイズと256色、または800x600ピクセルサイズと16色）。
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.
2. 特定のプロトコルのコンテキストでのネゴシエーションの展開に関連する特定の目標（たとえば、HTTPプロトコル操作、キャッシュインタラクション、セキュリティ問題、既存のHTTP交渉メカニズム、バリアント選択への応用など）との関係）。これらは、ネゴシエーションフレームワークのための特定のプロトコルバインディングによって対処されます。
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.
指定された目標の1つは、必要に応じて、プロキシとキャッシュが交渉プロセスに参加できるようにすることであることに注意してください。
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タイプ「MultiPart/Alternative」を使用して、複数のバージョンのリソースを送信できます。これにより、追加の帯域幅を使用してより多くのデータを送信することでレイテンシを保持します。一方、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 虚偽の交渉データの注入。
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 ネゴシエーションメタデータの認証は、潜在的なメッセージ送信者が他の当事者によって注入された誤った情報を使用しないようにする手段を提供します。
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など）を介して交渉交換を行うと、交渉データの交換における両当事者の相互認証を提供できます。
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.
このメモのいくつかの資料は、Koen Holtman、Andrew Mutz、Ted Hardie、Larry Masinter、Dan Wing、Neil Joffeによる以前のメモから派生しています。コンテンツ交渉の重要性と関連性の低いユーザーに対する関連性に関する問題は、Al Gilmanによって提起されました。
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] Freed、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] Freed、N。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[3] Holtman, K., et al., "The Alternates Header Field", Work in Progress.
[3] Holtman、K.、et al。、「The Alternates Headerフィールド」、進行中の作業。
[4] Hardie, T., "Scenarios for the Delivery of Negotiated Content", Work in Progress.
[4] Hardie、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] Wing、D。、「DSNおよびMDNへの拡張機能を使用したサポートされているメディア機能を示す」、RFC 2530、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] Fielding、R.、Gettys、J.、Mogul、J.、Frytyk、H。and T. Berners-Lee、「Hyptertext Transfer Protocol-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] Blaize、E。およびD. Pinkas、「シンプルで保護された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.
Phone: +44 1491 641 641 +44 118 930 1300
Fax: +44 1491 641 611 +44 118 930 1301
EMail: GK@ACM.ORG
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。