Network Working Group G. Klyne
Request for Comments: 2703 5GM/Content Technologies
Category: Informational September 1999
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.
许多Internet应用程序协议都需要为与之交互的资源提供内容协商。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
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
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.
许多Internet应用程序协议都需要为与之交互的资源提供内容协商。虽然MIME媒体类型[1，2]提供了处理一个长轴变化的标准方法，但资源也会以无法使用当前可用的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:
本备忘录的主要部分涉及四个主要方面：
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.
变量数据资源的几种可能表示形式之一。
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:
内容协商包括三个要素：
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 ]
[ 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.
协商框架提供消息的发送方和接收方之间的协商元数据交换，从而确定发送方可以提供和接收方可以处理的数据格式。因此，有三个主要元素是协商过程的主题，它们的能力由协商元数据描述：发送方、传输的数据文件格式和接收方。
The life of a data resource may be viewed as:
数据资源的生命周期可被视为：
(C) (T) (F) [A]-->--[S]-->--[R]-->--[U]
（C） （T）（F）[A]-->--[S]-->--[R]-->--[U]
where:
哪里：
[A] = author of document
(C) = original document content
[S] = message sending system
(T) = transmitted data file (representation of (C))
[R] = receiving system
(F) = formatted (rendered) document data (presentation of (C))
[U] = user or consumer of a document
[A] = 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.
这里，是[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 收件人请求一个变体资源，并提供协商元数据（以“Accept”头的形式），允许服务器代表客户端进行选择。
Another, simpler example is that of fax negotiation: in this case the intended recipient declares its capabilities, and the sender chooses a message variant to match.
另一个更简单的例子是传真协商：在这种情况下，预期的收件人声明其功能，发送方选择一个消息变量进行匹配。
Each of these can be viewed as a particular case of the general negotiation process described above. Similar observations can be made regarding the use of directory services or MIME ' Multipart/alternative' in conjunction with e-mail message transmission.
其中每一项都可以被视为上述一般谈判过程的一个特殊情况。对于目录服务或MIME“Multipart/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 用于标记媒体功能和功能集的一个或多个命名方案。应该通过某种注册流程来支持这些功能，以确保名称的唯一性，并鼓励为常用功能使用通用词汇表。
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描述和编码指定有助于将通用协商框架合并到ASN.1派生的协议中，如X.400、X.500、LDAP和SNMP。
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:
这些目标分为两类：
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 在给定应用程序的上下文中，内容协商可以使用一种或几种方法来传输、存储或分发功能。
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?
协商过程中经常建议的第三方参与者的一个特定示例是使用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
在Internet上，可以进行一些带宽/延迟权衡。例如，在Internet电子邮件中，MIME类型“multipart/alternative”可用于发送多个版本的电子邮件
resource: this preserves latency by using additional bandwidth to send a greater volume of data. On the other hand, HTTP [7] suggests a negotiation mechanism which preserves bandwidth at the cost of introducing a round-trip delay (section 12.2, Agent-driven negotiation).
资源：这通过使用额外的带宽发送更大容量的数据来保持延迟。另一方面，HTTP[7]提出了一种协商机制，以引入往返延迟为代价保留带宽（第12.2节，代理驱动协商）。
To set against the negative performance impact of content negotiation, it is to be hoped that overall network efficiency is to be improved if it results in the most useful data format being delivered to its intended recipient, first time, almost every time.
为了消除内容协商对性能的负面影响，如果能够将最有用的数据格式第一次（几乎每次）交付给预期的接收者，则希望能够提高总体网络效率。
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.
内容协商的一个应用是实现满足能力较差的人的特定需求的消息内容的交付。披露这些信息可能使这些人成为利用其个人弱点进行攻击的潜在目标。
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 20451996年11月。
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part 2: Media Types", RFC 2046, November 1996.
[2] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第2部分：媒体类型”，RFC 20461996年11月。
[3] Holtman, K., et al., "The Alternates Header Field", Work in Progress.
[3] Holtman，K.等人，“交替标题字段”，正在进行的工作。
[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的扩展指示支持的媒体功能”，RFC2530，1999年3月。
[7] Fielding, R., Gettys, J., Mogul, J., Frytyk, H. and T. Berners-Lee, "Hyptertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[7] 菲尔丁，R.，盖蒂斯，J.，莫格尔，J.，弗莱蒂克，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] 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.
Graham Klyne第五代信息服务有限公司内容技术有限公司位于英国阿灵顿商业园Watlington Street 1220 Parkview 5号，泰晤士河上的Theale Henley，RG9 5AB Reading，RG7 4SA。
Phone: +44 1491 641 641 +44 118 930 1300
Fax: +44 1491 641 611 +44 118 930 1301
EMail: GK@ACM.ORG
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.
版权所有（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编辑功能的资金目前由互联网协会提供。