Network Working Group G. Klyne
Request for Comments: 3297 Clearswift Corporation
Category: Standards Track R. Iwazaki
Toshiba TEC
D. Crocker
Brandenburg InternetWorking
July 2002
Network Working Group G. Klyne
Request for Comments: 3297 Clearswift Corporation
Category: Standards Track R. Iwazaki
Toshiba TEC
D. Crocker
Brandenburg InternetWorking
July 2002
Content Negotiation for Messaging Services based on Email
基于电子邮件的消息服务内容协商
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet email.
本备忘录描述了传真、语音和其他使用Internet电子邮件的消息服务的内容协商机制。
Services such as facsimile and voice messaging need to cope with new message content formats, yet need to ensure that the content of any given message is renderable by the receiving agent. The mechanism described here aims to meet these needs in a fashion that is fully compatible with the current behaviour and expectations of Internet email.
传真和语音消息等服务需要处理新的消息内容格式，但需要确保任何给定消息的内容可由接收代理呈现。这里描述的机制旨在以一种完全符合互联网电子邮件当前行为和期望的方式满足这些需求。
Table of Contents
目录
1. Introduction................................................... 3
1.1 Structure of this document ................................. 4
1.2 Document terminology and conventions ....................... 4
1.2.1 Terminology............................................ 4
1.2.2 Design goals........................................... 5
1.2.3 Other document conventions............................. 5
2. Background and goals........................................... 5
2.1 Background ................................................. 5
2.1.1 Fax and email.......................................... 5
2.1.2 Current facilities in Internet Fax..................... 6
2.2 Closing the loop ........................................... 6
1. Introduction................................................... 3
1.1 Structure of this document ................................. 4
1.2 Document terminology and conventions ....................... 4
1.2.1 Terminology............................................ 4
1.2.2 Design goals........................................... 5
1.2.3 Other document conventions............................. 5
2. Background and goals........................................... 5
2.1 Background ................................................. 5
2.1.1 Fax and email.......................................... 5
2.1.2 Current facilities in Internet Fax..................... 6
2.2 Closing the loop ........................................... 6
2.3 Goals for content negotiation .............................. 8
3. Framework for content negotiation..............................10
3.1 Send data with an indication of alternatives ...............11
3.1.1 Choice of default data format..........................12
3.1.2 MDN request indicating alternate data formats..........12
3.1.3 Information about alternative data formats.............13
3.2 Receiver options ...........................................14
3.2.1 Alternatives not recognized............................14
3.2.2 Alternative not desired................................14
3.2.3 Alternative preferred..................................14
3.3 Send alternative message data ..............................16
3.4 Confirm receipt of resent message data .....................17
4. The Content-alternative header.................................18
5. The Original-Message-ID message header.........................18
6. MDN extension for alternative data.............................19
6.1 Indicating readiness to send alternative data ..............19
6.2 Indicating a preference for alternative data ...............20
6.3 Indicating alternative data is no longer available .........21
6.4 Indicating loss of original data ...........................22
6.5 Automatic sending of MDN responses .........................22
7. Internet Fax Considerations....................................22
8. Examples.......................................................23
8.1 Sending enhanced Internet Fax image ........................23
8.2 Internet fax with initial data usable ......................27
8.3 Negotiate to lower receiver capability .....................28
8.4 Sending an alternative content type ........................32
9. IANA Considerations............................................36
9.1 New message headers ........................................36
9.2 MDN extensions .............................................36
9.2.1 Notification option 'Alternative-available'............36
9.2.2 Notification option 'Alternative-not-available'........36
9.2.3 Disposition modifier 'Alternative-preferred'...........37
9.2.4 Disposition modifier 'Original-lost'...................37
10. Internationalization considerations...........................37
11. Security Considerations.......................................37
12. Acknowledgements..............................................38
13. References....................................................38
Appendix A: Implementation issues.................................40
A.1 Receiver state .............................................40
A.2 Receiver buffering of message data .........................41
A.3 Sender state ...............................................42
A.4 Timeout of offer of alternatives ...........................42
A.5 Timeout of receiver capabilities ...........................42
A.6 Relationship to timely delivery ............................43
A.7 Ephemeral capabilities .....................................43
A.8 Situations where MDNs must not be auto-generated ...........44
Appendix B: Candidates for further enhancements...................44
Authors' Addresses................................................45
2.3 Goals for content negotiation .............................. 8
3. Framework for content negotiation..............................10
3.1 Send data with an indication of alternatives ...............11
3.1.1 Choice of default data format..........................12
3.1.2 MDN request indicating alternate data formats..........12
3.1.3 Information about alternative data formats.............13
3.2 Receiver options ...........................................14
3.2.1 Alternatives not recognized............................14
3.2.2 Alternative not desired................................14
3.2.3 Alternative preferred..................................14
3.3 Send alternative message data ..............................16
3.4 Confirm receipt of resent message data .....................17
4. The Content-alternative header.................................18
5. The Original-Message-ID message header.........................18
6. MDN extension for alternative data.............................19
6.1 Indicating readiness to send alternative data ..............19
6.2 Indicating a preference for alternative data ...............20
6.3 Indicating alternative data is no longer available .........21
6.4 Indicating loss of original data ...........................22
6.5 Automatic sending of MDN responses .........................22
7. Internet Fax Considerations....................................22
8. Examples.......................................................23
8.1 Sending enhanced Internet Fax image ........................23
8.2 Internet fax with initial data usable ......................27
8.3 Negotiate to lower receiver capability .....................28
8.4 Sending an alternative content type ........................32
9. IANA Considerations............................................36
9.1 New message headers ........................................36
9.2 MDN extensions .............................................36
9.2.1 Notification option 'Alternative-available'............36
9.2.2 Notification option 'Alternative-not-available'........36
9.2.3 Disposition modifier 'Alternative-preferred'...........37
9.2.4 Disposition modifier 'Original-lost'...................37
10. Internationalization considerations...........................37
11. Security Considerations.......................................37
12. Acknowledgements..............................................38
13. References....................................................38
Appendix A: Implementation issues.................................40
A.1 Receiver state .............................................40
A.2 Receiver buffering of message data .........................41
A.3 Sender state ...............................................42
A.4 Timeout of offer of alternatives ...........................42
A.5 Timeout of receiver capabilities ...........................42
A.6 Relationship to timely delivery ............................43
A.7 Ephemeral capabilities .....................................43
A.8 Situations where MDNs must not be auto-generated ...........44
Appendix B: Candidates for further enhancements...................44
Authors' Addresses................................................45
Full Copyright Statement..........................................46
Full Copyright Statement..........................................46
This memo describes a mechanism for email based content negotiation which provides an Internet fax facility comparable to that of traditional facsimile, which may be used by other messaging services that need similar facilities.
本备忘录描述了一种基于电子邮件的内容协商机制，该机制提供了与传统传真相当的互联网传真设施，可供需要类似设施的其他消息服务使用。
"Extended Facsimile using Internet Mail" [1] specifies the transfer of image data using Internet email protocols. "Indicating Supported Media Features Using Extensions to DSN and MDN" [2] describes a mechanism for providing the sender with the details of a receiver's capabilities. The capability information thus provided, if stored by the sender, can be used in subsequent transfers between the same sender and receiver.
“使用互联网邮件的扩展传真”[1]指定使用互联网电子邮件协议传输图像数据。“使用DSN和MDN扩展指示支持的媒体功能”[2]描述了一种向发送方提供接收方能力详细信息的机制。由此提供的能力信息如果由发送方存储，则可用于同一发送方和接收方之间的后续传输。
Many communications are one-off or infrequent transfers between a given sender and receiver, and cannot benefit from this "do better next time" approach.
许多通信是给定发送方和接收方之间的一次性或不频繁的传输，不能从这种“下次做得更好”的方法中获益。
An alternative facility available in email (though not widely implemented) is for the sender to use 'multipart/alternative' [15] to send a message in several different formats, and allow the receiver to choose. Apart from the obvious drawback of network bandwidth use, this approach does not of itself allow the sender to truly tailor its message to a given receiver, or to obtain confirmation that any of the alternatives sent was usable by the receiver.
电子邮件中提供的另一种功能（虽然没有广泛实施）是发送方使用“多部分/备选方案”[15]以几种不同的格式发送消息，并允许接收方选择。除了网络带宽使用的明显缺点外，这种方法本身不允许发送方真正地根据给定的接收方定制其消息，或获得接收方可用发送的任何备选方案的确认。
This memo describes a mechanism that allows better-than-baseline data formats to be sent in the first communication between a sender and receiver. The same mechanism can also achieve a usable message transfer when the sender has based the initial transmission on incorrect information about the receiver's capabilities. It allows the sender of a message to indicate availability of alternative formats, and the receiver to indicate that an alternative format should be provided to replace the message data originally transmitted.
本备忘录描述了一种机制，允许在发送方和接收方之间的第一次通信中发送优于基线的数据格式。当发送方基于关于接收方能力的错误信息进行初始传输时，同样的机制也可以实现可用的消息传输。它允许消息的发送方指示替代格式的可用性，而接收方指示应提供替代格式以替换最初传输的消息数据。
When the sender does not have the correct information about a receiver's capabilities, the mechanism described here may incur an additional message round trip. An important goal of this mechanism is to allow enough information to be provided to determine whether or not the extra round trip is required.
当发送方没有关于接收方能力的正确信息时，此处描述的机制可能导致额外的消息往返。该机制的一个重要目标是提供足够的信息，以确定是否需要额外的往返行程。
The main part of this memo addresses the following areas:
本备忘录的主要部分涉及以下方面：
Section 2 describes some of the background, and sets out some specific goals that are addressed in this specification.
第2节介绍了一些背景知识，并列出了本规范中涉及的一些具体目标。
Section 3 describes the proposed content negotiation framework, indicating the flow of information between a sender and receiver.
第3节描述了提议的内容协商框架，指出了发送方和接收方之间的信息流。
Section 4 contains a detailed description of the 'Content-alternative' header that is used to convey information about alternative available formats. This description is intended to stand independently of the rest of this specification, with a view to being usable in conjunction with other content negotiation protocols.
第4节包含“内容替代”标题的详细说明，该标题用于传达有关替代可用格式的信息。本说明旨在独立于本规范的其余部分，以便与其他内容协商协议结合使用。
Section 5 describes a new mail message header, 'Original-Message-ID', which is used to correlate alternative data sent during negotiation with the original message data, and to distinguish the continuation of an old message transaction from the start of a new transaction.
第5节描述了新邮件消息头“原始消息ID”，用于将协商期间发送的备选数据与原始消息数据关联起来，并区分旧消息事务的继续和新事务的开始。
Section 6 describes extensions to the Message Disposition Notification (MDN) framework [4] that support negotiation between the communicating parties.
第6节描述了消息处置通知（MDN）框架[4]的扩展，该框架支持通信双方之间的协商。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [22].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[22]中所述进行解释。
Capability exchange An exchange of information between communicating parties indicating the kinds of information they can generate or consume.
能力交换通信双方之间的信息交换，表明他们可以生成或使用的信息类型。
Capability identification Provision of information by the a receiving agent that indicates the kinds of message data that it can accept for presentation to a user.
能力识别由接收代理提供的信息，指示它可以接受的消息数据类型，以便向用户呈现。
Content negotiation An exchange of information (negotiation metadata) which leads to selection of the appropriate representation (variant) when transferring a data resource.
内容协商信息交换（协商元数据），在传输数据资源时选择适当的表示（变量）。
Message transaction
消息事务
A sequence of exchanges between a message sender and receiver that accomplish the transfer of message data.
报文发送方和接收方之间完成报文数据传输的一系列交换。
RFC 2703 [17] introduces several other terms related to content negotiation.
RFC 2703[17]介绍了与内容协商相关的几个其他术语。
In discussing the goals for content negotiation, {1}, {2}, {3} notation is used, per RFC 2542, "Terminology and Goals for Internet Fax" [3]. The meanings associated with these notations are:
在讨论内容协商的目标时，根据RFC 2542，“互联网传真的术语和目标”[3]，使用了{1}、{2}、{3}符号。与这些符号相关的含义如下：
{1} there is general agreement that this is a critical characteristic of any definition of content negotiation for Internet Fax.
{1} 人们普遍认为，这是互联网传真内容协商定义的一个关键特征。
{2} most believe that this is an important characteristic of content negotiation for Internet Fax.
{2} 大多数人认为这是互联网传真内容协商的一个重要特征。
{3} there is general belief that this is a useful feature of content negotiation for Internet Fax, but that other factors might override; a definition that does not provide this element is acceptable.
{3} 人们普遍认为，这是互联网传真内容协商的一个有用特征，但其他因素可能会优先考虑；不提供此元素的定义是可接受的。
NOTE: Comments like this provide additional nonessential information about the rationale behind this document. Such information is not needed for building a conformant implementation, but may help those who wish to understand the design in greater depth.
注：此类评论提供了有关本文件背后的基本原理的其他非必要信息。构建一致性实现不需要这些信息，但可以帮助那些希望更深入地理解设计的人。
One of the goals of the work to define a facsimile service using Internet mail has been to deliver benefits of the traditional Group 3 Fax service in an email environment. Traditional Group 3 Fax leans heavily on the idea that an online exchange of information discloses a receiver's capabilities to the sender before any message data is transmitted.
定义使用Internet邮件的传真服务的工作目标之一是在电子邮件环境中提供传统的第3组传真服务的好处。传统的第3组传真严重依赖于这样一种理念，即在线信息交换在任何消息数据传输之前向发送方披露接收方的能力。
By contrast, Internet mail has been developed to operate in a different fashion, without any expectation that the sender and receiver will exchange information prior to message transfer. One consequence of this is that all mail messages must contain some kind of meaningful message data: messages that are sent simply to elicit information from a receiving message handling agent are not generally acceptable in the Internet mail environment.
相比之下，互联网邮件已发展为以不同的方式运作，没有任何期望发送者和接收者将在消息传输之前交换信息。这样做的一个结果是，所有邮件消息都必须包含某种有意义的消息数据：发送消息只是为了从接收消息处理代理获取信息，在Internet邮件环境中通常是不可接受的。
To guarantee some level of interoperability, Group 3 Fax and Internet mail rely on all receivers being able to deal with some baseline format (i.e., a basic image format or plain ASCII text, respectively). The role of capability exchange or content negotiation is to permit better-than baseline capabilities to be employed where available.
为了保证一定程度的互操作性，第3组传真和互联网邮件依赖于所有接收者能够处理一些基线格式（即，分别为基本图像格式或纯ASCII文本）。能力交换或内容协商的作用是允许在可用的情况下使用优于基线的能力。
One of the challenges addressed by this specification is how to adapt the email environment to provide a fax-like service. A sender must not make any a priori assumption that the receiver can recognize anything other than a simple email message. There are some important uses of email that are fundamentally incompatible with the fax model of message passing and content negotiation (notably mailing lists). So we need to have a way of recognizing when content negotiation is possible, without breaking the existing email model.
本规范解决的挑战之一是如何调整电子邮件环境以提供类似传真的服务。发送方不得做出任何先验假设，即接收方可以识别除简单电子邮件以外的任何内容。电子邮件的一些重要用途与消息传递和内容协商的传真模式（尤其是邮件列表）根本不兼容。因此，我们需要有一种在不破坏现有电子邮件模型的情况下识别何时可以进行内容协商的方法。
"Extended Facsimile using Internet Mail" [1] provides for a limited provision of receiver capability information to the sender of a message, using an extension to Message Disposition Notifications [2,4], employing media feature tags [5] and media feature expressions [6].
“使用互联网邮件的扩展传真”[1]使用消息处置通知的扩展[2,4]，使用媒体功能标签[5]和媒体功能表达式[6]，为消息的发送者提供有限的接收方能力信息。
This mechanism provides for receiver capabilities to be disclosed after a message has been received and processed. This information can be used for subsequent transmissions to the same receiver. But many communications are one-off messages from a given sender to a given receiver, and cannot benefit from this.
该机制提供了在接收和处理消息之后要公开的接收器功能。该信息可用于到同一接收机的后续传输。但许多通信是从给定发送者到给定接收者的一次性消息，不能从中受益。
Classic Internet mail is an "open loop" process: no information is returned back to the point from which the message is sent. This has been unkindly --but accurately-- characterized as "send and pray", since it lacks confirmation.
经典的Internet邮件是一个“开环”过程：没有信息返回到邮件发送点。这被无情地——但准确地——描述为“发送并祈祷”，因为它缺乏确认。
Sending a message and obtaining confirmation that the message has been received is a "closed loop" process: the confirmation sent back to the sender creates a loop around which information is passed.
发送消息并获得消息已被接收的确认是一个“闭环”过程：发送回发送者的确认创建了一个信息传递的循环。
Many Internet email agents are not designed to participate in a closed loop process, and thus have no responsibility to respond to receipt of a message. Later additions to Internet standards, notably Delivery Service Notification [18] and Message Disposition Notification [4], specify means for certain confirmation responses to be sent back to the sender, thereby closing the loop. However conformance to these enhancements is optional and full deployment is in the future.
许多Internet电子邮件代理不是为参与闭环过程而设计的，因此没有责任对收到的消息做出响应。后来对互联网标准的补充，特别是交付服务通知[18]和消息处置通知[4]，规定了将某些确认响应发送回发送方的方式，从而关闭了循环。但是，对这些增强功能的一致性是可选的，并且完全部署将在将来进行。
DSN must be fully implemented by the entire infrastructure; further when support is lacking, the message is still sent on in open-loop fashion. Sometimes, transmission and delivery should instead be aborted and the fact be reported to the sender.
DSN必须由整个基础设施全面实施；此外，当缺少支持时，消息仍然以开环方式发送。有时，应该中止传输和传递，并将事实报告给发送方。
Due to privacy considerations for end-users, MDN usage is entirely voluntary.
出于对最终用户隐私的考虑，MDN的使用完全是自愿的。
Content negotiation is a closed loop function (for the purposes of this proposal -- see section 2.3, item (f)), and requires that the recipient of a message make some response to the sender. Since content negotiation must retro-fit a closed-loop function over Internet mail's voluntary and high-latency environment, a challenge for content negotiation in email is to establish that consenting parties can recognize a closed loop situation, and hence recognize their responsibilities to close the loop.
内容协商是一种闭环功能（就本提案而言，请参见第2.3节第（f）项），它要求消息的接收者向发送者做出一些响应。由于内容协商必须在互联网邮件的自愿和高延迟环境中重新适应闭环功能，电子邮件中内容协商的一个挑战是确定同意方可以识别闭环情况，从而识别其关闭环路的责任。
Three different loops can be identified in a content negotiation:
在内容协商中可以识别三个不同的循环：
Sender Receiver
| |
Initial message ------>------------ v
| |
(1) ------------<--- Request alternative data
| |
Send alternative ------>------------ (2)
| |
(3) ------------<------ Confirm receipt
of usable data
Sender Receiver
| |
Initial message ------>------------ v
| |
(1) ------------<--- Request alternative data
| |
Send alternative ------>------------ (2)
| |
(3) ------------<------ Confirm receipt
of usable data
(1) Sender receives acknowledgement that negotiable content has been received
(1) 发送方收到已收到可协商内容的确认
(2) Receiver receives confirmation that its request for data has been received.
(2) 接收方收到已收到其数据请求的确认。
(3) Sender receives confirmation that received data is processable, or has been processed.
(3) 发送方收到接收到的数据可处理或已处理的确认。
Although the content negotiation process is initiated by the sender, it is not established until loop (1) is closed with an indication that the receiver desires alternative content.
尽管内容协商过程是由发送方发起的，但直到循环（1）关闭并指示接收方希望替代内容时，内容协商过程才建立。
If content sent with the original message from the sender is processable by the receiver, and a confirmation is sent, then the entire process is reduced to a simple send/confirm loop:
如果接收方可以处理从发送方随原始消息发送的内容，并发送确认，则整个过程将简化为一个简单的发送/确认循环：
Sender Receiver
| |
Initial message ------>------------ v
| |
(3) ------------<------ Confirm receipt
of usable data
Sender Receiver
| |
Initial message ------>------------ v
| |
(3) ------------<------ Confirm receipt
of usable data
The primary goal {1} is to provide a mechanism that allows arbitrary enhanced content features to be used with Internet fax systems. The mechanism should {2} support introduction of new features over time, particularly those that are adopted for Group 3 fax.
主要目标{1}是提供一种机制，允许在Internet传真系统中使用任意增强的内容功能。该机制应{2}支持随着时间的推移引入新功能，特别是第3组传真采用的功能。
Further goals are:
进一步的目标是：
(a) Must {1} interwork with existing simple mode Internet fax systems.
(a) 必须{1}与现有的简单模式Internet传真系统互通。
(b) Must {1} interwork with existing email clients.
(b) 必须{1}与现有电子邮件客户端交互。
The term "interwork" used above means that the mechanism must be introduced in a way that may be ignored by existing systems, and systems enhanced to use the negotiation mechanisms will behave in a fashion that is expected by existing systems. (I.e., existing clients are not expected in any way to participate in or be aware of content negotiation.)
上面使用的术语“互通”意味着必须以现有系统可能忽略的方式引入该机制，并且为使用协商机制而增强的系统将以现有系统预期的方式运行。（即，现有客户不希望以任何方式参与或意识到内容协商。）
(c) Must {1} avoid transmission of "administrative non messages". (I.e., only messages that contain meaningful content for the end user may be sent unless it is known that the receiving system will interpret them, and not attempt to display them.) This requirement has been stated very strongly by the email community.
(c) 必须{1}避免传输“管理非消息”。（即，只有包含对最终用户有意义的内容的消息才能发送，除非已知接收系统将解释它们，而不是试图显示它们。）电子邮件社区已经非常明确地说明了这一要求。
This means that a sender must not assume that a receiver can understand the capability exchange protocol elements, so must always start by sending some meaningful message data.
这意味着发送方不能假设接收方能够理解能力交换协议元素，因此必须始终从发送一些有意义的消息数据开始。
(d) Avoid {1} multiple renderings of a message. In situations where multiple versions of a message are transferred, the receiver must be able to reliably decide on a single version to be displayed.
(d) 避免对消息进行{1}多次呈现。在传输多个版本的消息的情况下，接收方必须能够可靠地确定要显示的单个版本。
(e) Minimize {2} round trips needed to complete a transmission. Ideally {3} every enhanced transmission will result in simply sending data that the recipient can process, and receiving a confirmation response.
(e) 尽量减少完成传输所需的{2}往返行程。理想情况下{3}每一次增强的传输都只需发送接收者可以处理的数据，并接收确认响应。
(f) The solution adopted should not {3} transmit multiple versions of the same data. In particular, it must not {1} rely on routinely sending multiple instances of the same data in a single message.
(f) 所采用的解决方案不应{3}传输同一数据的多个版本。特别是，它不能{1}依赖于在一条消息中定期发送同一数据的多个实例。
This does not prohibit sending multiple versions of the same data, but it must not be a requirement to do so. A sender may choose to send multiple versions together (e.g., plain text and some other format), but the capability exchange mechanism selected must not depend on such behaviour.
这并不禁止发送同一数据的多个版本，但不一定要求这样做。发送方可以选择同时发送多个版本（例如，纯文本和其他格式），但选择的功能交换机制不得依赖于此类行为。
(g) The solution adopted should {2} be consistent with and applicable to other Internet email based applications; e.g., regular email, voice messaging, unified messaging, etc.
(g) 所采用的解决办法应{2}符合并适用于其他基于互联网电子邮件的应用程序；e、 例如，常规电子邮件、语音消息、统一消息等。
(h) Allow for a graceful recovery from stale cache information. A sender might use historic information to send non-baseline data with an initial message. If this turns out to be unusable by the recipient, it should still be possible {3} for the baseline data, or some other acceptable format, to be selected and transferred.
(h) 允许从过时的缓存信息进行正常恢复。发送方可以使用历史信息发送带有初始消息的非基线数据。如果收件人无法使用，则仍有可能选择并传输基线数据或其他可接受的格式。
(i) The mechanism defined should {2} operate cleanly in conjunction with the mechanisms already defined for extended mode Internet fax (extended DSN and MDN [2], etc.).
(i) 定义的机制应{2}与已为扩展模式Internet传真定义的机制（扩展DSN和MDN[2]等）一起干净地运行。
(j) As much as possible, existing email mechanisms should {3} be used rather than inventing new ones. (It is clear that some new mechanisms will be needed, but they should be defined cautiously.)
(j) 应该尽可能地使用现有的电子邮件机制，而不是发明新的机制。（显然需要一些新的机制，但应该谨慎定义。）
(k) The mechanism should {2} be implementable in low memory devices. That is, it should not depend on any party being able to buffer arbitrary amounts of message data.
(k) 该机制应{2}可在低内存设备中实现。也就是说，它不应该依赖于任何一方能够缓冲任意数量的消息数据。
(It may not be possible to completely satisfy this goal in a sending system. But if the sender does not have enough memory to buffer some given message, it can choose to not offer content negotiation.)
（在发送系统中可能不可能完全满足这一目标。但如果发送者没有足够的内存来缓冲某些给定的消息，则可以选择不提供内容协商。）
This section starts with an outline of the negotiation process, and provides greater detail about each stage in following sub-sections.
本节首先概述了谈判过程，并在以下小节中详细介绍了每个阶段。
1. Sender sends initial message data with an indication of alternative formats available (section 3.1). Initial data MAY be a baseline or some other guess of what the recipient can handle.
1. 发送方发送初始消息数据，并指示可用的替代格式（第3.1节）。初始数据可能是一个基线，也可能是对接收者可以处理什么的其他猜测。
2. The receiver has three main options:
2. 接收器有三个主要选项：
(a) Does not recognize the optional alternative formats, and passively accepts the data as sent (section 3.2.1).
(a) 不识别可选替代格式，被动接受发送的数据（第3.2.1节）。
(b) Does recognize the alternatives offered, and actively accepts the data as sent (section 3.2.2).
(b) 确认提供的备选方案，并积极接受发送的数据（第3.2.2节）。
(c) Recognizes the alternatives offered, and determines that it prefers to receive an alternative format. An MDN response is sent (i) indicating that the original data was not processed, and (ii) containing receiver capability information so that the sender may select a suitable alternative (section 3.2.3).
(c) 识别提供的备选方案，并确定其更愿意接收备选格式。发送MDN响应（i）表明原始数据未被处理，以及（ii）包含接收方能力信息，以便发送方可以选择合适的替代方案（第3.2.3节）。
Note that only recipients named in 'to:', 'cc:' or 'bcc:' headers in the original message may request alternative data formats in this way. Recipients not named in the original message headers MUST NOT attempt to initiate content negotiation.
请注意，只有原始邮件中以“收件人：”、“抄送：”或“密件抄送：”标题命名的收件人才能以这种方式请求其他数据格式。原始邮件标题中未命名的收件人不得尝试启动内容协商。
NOTE: the prohibition on initiation of negotiation by recipients other than those explicitly addressed is to avoid the sender from having to deal with negotiation requests from unexpected parties.
注：禁止收件人发起谈判（明确提及的除外）是为了避免发件人不得不处理意外方的谈判请求。
3. On receipt of an MDN response indicating preference for an alternative data format, the sender MUST select and transmit message data matched to the receiver's declared capabilities, or send an indication that the receiver's request cannot be honoured. When sending alternative data, the sender suppresses the indication that alternative data is available, so the negotiation process cannot loop.
3. 在收到表明首选替代数据格式的MDN响应后，发送方必须选择并发送与接收方声明的能力相匹配的消息数据，或发送接收方的请求无法得到满足的指示。发送替代数据时，发送方会抑制替代数据可用的指示，因此协商过程无法循环。
4. On receipt of final data from the sender, the receiver sends an MDN response indicating acceptance (or otherwise) of the data received.
4. 在接收到来自发送方的最终数据时，接收方发送一个MDN响应，指示接受（或以其他方式）所接收的数据。
NOTE: the receiver does not choose the particular data format to be received; that choice rests with the sender. We find that this approach is simpler than having the receiver choose an alternative, because it builds upon existing mechanisms in email, and follows the same pattern as a traditional Group 3 fax. Further, it deals with situations where the range of alternatives may be difficult to describe.
注意：接收器不选择要接收的特定数据格式；这一选择取决于发送者。我们发现，这种方法比让接收者选择另一种方法更简单，因为它建立在电子邮件中现有的机制之上，并遵循与传统的第3组传真相同的模式。此外，它处理的情况下，替代范围可能难以描述。
This approach is similar to server driven negotiation in HTTP using "Accept" headers [13]. This is distinct to the agent-driven style of negotiation provided for HTTP as part of Transparent Content Negotiation [14], or which might be constructed in email using "multipart/alternative" and "message/external-body" MIME types [15].
这种方法类似于HTTP中使用“Accept”头的服务器驱动协商[13]。这与作为透明内容协商的一部分为HTTP提供的代理驱动的协商风格不同[14]，或者可以在电子邮件中使用“多部分/备选方案”和“消息/外部主体”MIME类型构造协商风格[15]。
A sender that is prepared to provide alternative message data formats MUST send the following message elements:
准备提供替代邮件数据格式的发件人必须发送以下邮件元素：
(a) a default message data format,
(a) 默认消息数据格式，
(b) message identification, in the form of a Message-ID header.
(b) 消息标识，以消息ID头的形式。
(c) appropriate 'Content-features' header(s) [7] describing the default message data sent,
(c) 描述发送的默认消息数据的适当“内容特征”标题[7]，
(d) a request for Message Disposition Notification [4],
(d) 请求消息处置通知[4]，
(e) an indication that it is prepared to send different message data, using an 'Alternative-available' MDN option field [9], and
(e) 表示准备使用“可选可用”MDN选项字段[9]发送不同的消息数据，以及
(f) an indication of the alternative data formats available, in the form of 'Content-alternative' header(s) [8]. Note: more than one Content-alternative' header MAY be specified; see section 3.1.3 for more information.
(f) 可用替代数据格式的指示，以“内容替代”标题的形式出现[8]。注：可指定多个“内容备选”标题；详见第3.1.3节。
Having indicated the availability of alternative data formats, the sender is expected to hold the necessary information for some time, allowing the receiver an opportunity to request such data. But, unless it so indicates (see [9]), the sender is not expected to hold this information indefinitely; the exact length of time such information should be held is not specified here. Thus, the
在表明了替代数据格式的可用性后，发送方应在一段时间内保留必要的信息，以便接收方有机会请求此类数据。但是，除非另有说明（见[9]），否则发送方不会无限期地持有该信息；此处未规定此类信息的确切保存时间。因此
possibility exists that a request for alternative information may arrive too late, and the sender will then send an indication that the data is no longer available. If message transference is being completed within a predetermined time interval (e.g., using [21]), then the sender should normally maintain the data for at least that period.
存在一种可能性，即对替代信息的请求可能来得太迟，然后发送方将发送一个数据不再可用的指示。如果消息传输在预定的时间间隔内完成（例如，使用[21]），则发送方通常应至少在该时间段内维护数据。
The normal default format is text/plain. This is the format sent unless the sender has prior knowledge or expectation of other content formats supported by the recipient. Some uses of email presume some other default format (e.g. Intenet fax [1] has TIFF profile S [11] as its default format; see section 7 of this document).
正常默认格式为文本/普通。这是发送的格式，除非发件人事先知道或期望收件人支持其他内容格式。电子邮件的某些用途假定其他默认格式（例如，Intenet fax[1]将TIFF profile S[11]作为其默认格式；请参阅本文档第7节）。
"Extended Facsimile Using Internet Mail" [1] and "Indicating Supported Media Features Using Extensions to DSN and MDN" [2] indicate a possible mechanism for a sender to have prior knowledge of receiver capabilities. This specification builds upon the mechanism described there.
“使用互联网邮件的扩展传真”[1]和“使用DSN和MDN的扩展指示支持的媒体功能”[2]表示发送方事先了解接收方能力的可能机制。本规范以此处描述的机制为基础。
As always, the sender may gather information about the receiver in other ways beyond the scope of this document (e.g., a directory service or the suggested RESCAP protocol).
与往常一样，发送方可以通过本文档范围以外的其他方式（例如，目录服务或建议的重新映射协议）收集有关接收方的信息。
When a sender is indicating preparedness to send alternative message data, it MUST request a Message Disposition Notification (MDN) [4].
当发送方指示准备发送备用消息数据时，它必须请求消息处置通知（MDN）[4]。
It indicates its readiness to send alternative message data by including the MDN option 'Alternative-available' [9] with the MDN request. Presence of this MDN request option simply indicates that the sender is prepared to send some different data format if it has more accurate or up-to-date information about the receiver's capabilities. Of itself, this option does not indicate whether the alternatives are likely to be better or worse than the default data sent -- that information is provided by the "Content-alternative" header(s) [8].
它通过在MDN请求中包含MDN选项“alternative available”[9]来表示其已准备好发送替代消息数据。此MDN请求选项的存在仅表示发送方准备发送一些不同的数据格式，前提是它具有关于接收方能力的更准确或最新信息。就其本身而言，该选项并不表示备选方案是否可能比发送的默认数据更好或更差——该信息由“内容备选方案”标题提供[8]。
When using the 'Alternative-available' option in an MDN request, the message MUST also contain a 'Message-ID:' header with a unique message identifier.
在MDN请求中使用“可选可用”选项时，消息还必须包含具有唯一消息标识符的“消息ID:”标头。
A sender can provide information about the alternative message data available by applying one or more 'Content-alternative' headers to message body parts for which alternative data is available, each indicating media features [5,6] of an available alternative.
发送方可以通过将一个或多个“内容替代”标题应用于具有替代数据的邮件正文部分来提供关于可用替代邮件数据的信息，每个标题指示可用替代邮件的媒体特征[5,6]。
The purpose of this information is to allow a receiver to decide whether any of the available alternatives are preferable, or likely to be preferable, to the default message data provided.
该信息的目的是允许接收者决定可用备选方案中的任何一个是否比所提供的默认消息数据更可取，或可能更可取。
Not every available alternative is required to be described in this way, but the sender should include enough information to allow a receiver to determine whether or not it can expect more useful message data if it chooses to indicate a preference for some alternative that matches its capabilities.
并非所有可用的备选方案都需要以这种方式描述，但发送方应包含足够的信息，以允许接收方确定，如果它选择指示对与其能力相匹配的某个备选方案的偏好，是否可以期望更有用的消息数据。
Alternative formats will often be variations of the content-type originally sent. When different content-types can be provided, they should be indicated in a corresponding content-alternative header using the 'type' media feature tag [24]. (See example 8.4.)
替代格式通常是最初发送的内容类型的变体。当可以提供不同的内容类型时，应使用“类型”媒体功能标签在相应的内容替代标题中指示它们[24]。（参见示例8.4。）
NOTE: the sender is not necessarily expected to describe every single alternative format that is available -- indeed, in cases where content is generated on-the-fly rather than simply selected from an enumeration of possibilities, this may be infeasible. The sender is expected to use one or more 'Content-alternative' headers to reasonably indicate the range of alternative formats available.
注意：发送者不一定要描述每一种可用的替代格式——事实上，如果内容是动态生成的，而不是简单地从列举的可能性中选择，这可能是不可行的。发送方应使用一个或多个“内容替代”标题合理指示可用替代格式的范围。
The final format actually sent will always be selected by the sender, based on the receiver's capabilities. The 'Content-alternative' headers are provided here simply to allow the receiver to make a reasonable decision about whether to request an alternative format that better matches its capabilities.
实际发送的最终格式将始终由发送方根据接收方的能力选择。这里提供的“Content alternative”标题只是为了让接收者做出合理的决定，决定是否请求更符合其功能的替代格式。
ALSO NOTE: this header is intended to be usable independently of the MDN extension that indicates the sender is prepared to send alternative formats. It could be used with a different protocol having nothing to do with email or MDN. Thus, the 'Content-alternative' header provides information about alternative data formats without actually indicating if or how they might be obtained.
另请注意：此标头旨在独立于MDN扩展而使用，MDN扩展指示发送方准备发送替代格式。它可以与与电子邮件或MDN无关的其他协议一起使用。因此，“Content alternative”（内容替代）标题提供了关于替代数据格式的信息，而没有实际指示是否或如何获得它们。
Further, the 'Content-alternative' header applies to a MIME body part, where the MDN 'Alternative-available' option applies to the message as a whole.
此外，“Content alternative”头应用于MIME正文部分，其中MDN“alternative available”选项应用于整个消息。
The example sections of this memo show how the 'Content-features:' and 'Content-alternative:' MIME headers may be used to describe the content provided and available alternatives.
本备忘录的示例部分显示了如何使用“Content features:”和“Content alternative:”MIME头来描述提供的内容和可用的备选方案。
A negotiation-aware system receiving message data without an indication of alternative data formats MUST process that message in the same way as a standard Internet fax system or email user agent.
接收消息数据而不指示替代数据格式的协商感知系统必须以与标准Internet传真系统或电子邮件用户代理相同的方式处理该消息。
Given an indication of alternative data format options, the receiver has three primary options:
给定替代数据格式选项的指示，接收器有三个主要选项：
(a) do not recognize the alternatives: passively accept what is provided,
(a) 不承认备选方案：被动接受提供的方案，
(b) do not prefer the alternatives: actively accept what is provided, or
(b) 不喜欢替代方案：积极接受所提供的，或
(c) prefer some alternative format.
(c) 喜欢其他格式。
This corresponds to the case that the receiver is a simple mode Internet fax recipient [12], or a traditional email user agent.
这对应于接收者是简单模式互联网传真接收者[12]或传统电子邮件用户代理的情况。
The receiver does not recognize the alternatives offered, or chooses not to recognize them, and simply accepts the data as sent. A standard MDN response [4] or an extended MDN response [2] MAY be generated at the receiver's option.
接收者不识别提供的备选方案，或者选择不识别它们，只是接受发送的数据。标准MDN响应[4]或扩展MDN响应[2]可由接收机选择生成。
The receiver does recognize the alternatives offered, but specifically chooses to accept the data originally offered. An MDN response SHOULD be sent indicating acceptance of the data and also containing the receiver's capabilities.
接收者确实认识到提供的备选方案，但特别选择接受最初提供的数据。应发送MDN响应，指示接受数据，并包含接收器的能力。
This is the same as the defined behaviour of an Extended Internet Fax receiver [1,2].
这与扩展Internet传真接收器的定义行为相同[1,2]。
This case extends the behaviour of Extended Internet Fax [1,2] to allow an alternative form of data for the current message to be transferred. This option may be followed ONLY if the original message contains an 'Alternative-available' MDN option (alternative
本案例扩展了扩展Internet传真[1,2]的行为，以允许传输当前消息的另一种数据形式。仅当原始消息包含“可选可用”MDN选项（可选）时，才可以使用此选项
data re-sends may not use this option). Further, this option may be followed ONLY if the recipient is explicitly addressed in the message headers ('to:', 'cc:' or 'bcc:').
数据重新发送可能不使用此选项）。此外，仅当收件人在邮件标题中明确寻址（“收件人：”、“抄送：”或“密件抄送：”）时，才可以使用此选项。
The receiver recognizes that alternative data is available, and based on the information provided determines that an alternative format would be preferable. An MDN response [4] is sent, which MUST contain the following:
接收机认识到替代数据是可用的，并且基于所提供的信息确定替代格式将是优选的。已发送MDN响应[4]，该响应必须包含以下内容：
o an 'Alternative-preferred' disposition modifier [9] indicating that some data format other than that originally sent is preferred,
o “可选首选”处置修饰符[9]，表示首选最初发送的数据格式以外的某些数据格式，
o an 'Original-Message-ID:' field [4] with the message identifier from the received message, and
o “原始消息ID:”字段[4]，其中包含来自接收消息的消息标识符，以及
o receiver capabilities, per RFC 2530 [2].
o 根据RFC 2530[2]，接收机能力。
On sending such an MDN response, the receiver MAY discard the message data provided, in the expectation that some alternative will be sent. But if the sender has indicated a limited lifetime for the alternative data, and the original data received is within the receiver's capability to display, the receiver SHOULD NOT discard it. Lacking sufficient memory to hold the original data for a period of time within which alternative data would reasonably be received, the receiver SHOULD accept and display the original data. In the case that the original data is not within the receiver's capability to display then it SHOULD discard the original data and request an alternative format.
在发送这样的MDN响应时，接收机可以丢弃所提供的消息数据，期望将发送一些替代消息。但是，如果发送方已指示替代数据的使用期限有限，并且接收到的原始数据在接收方的显示能力范围内，则接收方不应丢弃该数据。由于缺乏足够的内存来保存原始数据一段时间，在这段时间内可以合理地接收替代数据，接收器应该接受并显示原始数据。如果原始数据不在接收器的显示能力范围内，则应丢弃原始数据并请求替代格式。
NOTE: the above rules are meant to ensure that the content negotiation framework does not result in the loss of data that would otherwise be received and displayed.
注意：上述规则旨在确保内容协商框架不会导致数据丢失，否则数据将被接收和显示。
Having requested alternative data and not displayed the original data, the receiver MUST remember this fact and be prepared to take corrective action if alternative data is not received within a reasonable time (e.g., if the MDN response or transmission of alternative data is lost in transit).
在请求替代数据且未显示原始数据后，接收方必须记住这一事实，并准备在合理时间内未收到替代数据时采取纠正措施（例如，如果MDN响应或替代数据传输在传输过程中丢失）。
Corrective action might be any of the following:
纠正措施可以是以下任何一种：
(a) re-send the MDN response, and continue waiting for an alternative,
(a) 重新发送MDN响应，并继续等待替代方案，
(b) present the data originally supplied (if it is still available), or
(b) 提供最初提供的数据（如果仍然可用），或
(c) generate an error response indicating loss of data.
(c) 生成指示数据丢失的错误响应。
On concluding that alternative data is not forthcoming, the preferred option is (b), but this may not be possible for receivers with limited memory.
在得出不提供替代数据的结论时，首选选项是（b），但对于内存有限的接收器来说，这可能是不可能的。
See Appendix A for further discussion of receiver behaviour options.
有关接收器行为选项的进一步讨论，请参见附录A。
NOTE: A cache control indicator on recipient capabilities has been considered, but is not included in this specification. (Sometimes, a recipient may want to offer certain capabilities only under certain circumstances, and does not wish them to be remembered for future use; e.g., not wanting to receive colour images for routine communications.)
注意：已考虑了收件人功能上的缓存控制指示器，但未包含在本规范中。（有时，接收者可能只希望在某些情况下提供某些功能，并且不希望记住这些功能以备将来使用；例如，不希望接收用于日常通信的彩色图像。）
NOTE: the receiver does not actually get to select any specific data format offered by the sender. The final choice of data format is always made by the sender, based on the receiver's declared capabilities. This approach:
注意：接收方实际上无法选择发送方提供的任何特定数据格式。数据格式的最终选择始终由发送方根据接收方声明的能力进行。这种方法：
(a) more closely matches the style of T.30 content negotiation,
(a) 更符合T.30内容协商的风格，
(b) provides for clean integration with the current extended mode Internet fax specification,
(b) 提供与当前扩展模式Internet传真规范的干净集成，
(c) builds upon existing email mechanisms in a consistent fashion, and
(c) 以一致的方式构建现有的电子邮件机制，以及
(d) allows for cases (e.g., dynamically generated content) where it is not feasible for the sender to enumerate the alternatives available.
(d) 允许在发送方无法列举可用替代方案的情况下（例如，动态生成的内容）。
Having offered to provide alternative data by including an 'Alternative-available' option with the original MDN request, and on receipt of an MDN response indicating 'Alternative-preferred', the sender SHOULD transmit alternative message data that best matches the receiver's declared capabilities. (In the exceptional case that the response requesting an alternative data format does not contain receiver capabilities, a baseline format should be selected.)
通过在原始MDN请求中包含“可选可用”选项提供可选数据，并且在收到指示“可选首选”的MDN响应后，发送方应传输与接收方声明的能力最匹配的可选消息数据。（在请求替代数据格式的响应不包含接收器功能的例外情况下，应选择基线格式。）
If any part of the best available message data matching the receiver capabilities is the same as that originally sent, it MUST still be re-transmitted because the receiver may have discarded the original data. Any data sent as a result of receiving an 'Alternative-preferred' response should include an MDN request but SHOULD NOT include an 'Alternative-available' disposition notification modifier.
如果与接收器功能匹配的最佳可用消息数据的任何部分与最初发送的相同，则仍必须重新发送，因为接收器可能已丢弃原始数据。由于收到“备选首选”响应而发送的任何数据应包括MDN请求，但不应包括“备选可用”处置通知修饰符。
If the sender is no longer able to send message data for any reason, it MUST send a message to the receiver indicating a failed transfer. It SHOULD also generate a report for the receiver indicating the failure, containing an MDN request and including an 'Alternative-not-available' disposition notification modifier.
如果发送方因任何原因无法再发送消息数据，则必须向接收方发送消息，表明传输失败。它还应该为接收方生成一个报告，指示失败，其中包含一个MDN请求，并包含一个“可选不可用”处置通知修饰符。
Any message sent to a receiver in response to a request for alternative data MUST include an 'Original-Message-ID:' header [23] containing the Original-message-ID value from the received disposition notification message (which is the 'Message-ID:' from the original message). This header serves to correlate the re-send (or failure message) with the original message, and also to distinguish a re-send from an original message.
为响应替代数据请求而发送给接收者的任何消息必须包含“原始消息ID:”标头[23]，其中包含接收到的处置通知消息中的原始消息ID值（即原始消息中的“消息ID:”）。此标头用于将重新发送（或失败消息）与原始消息关联起来，并将重新发送与原始消息区分开来。
When resent data is received (indicated by presence of an 'original-message-ID:' header field), the receiver processes that data and generates an MDN response indicating the final disposition of the data received, and also indicating capabilities that may be used for future messages, per RFC 2530 [2] and RFC 2532 [1].
当接收到重新发送数据时（通过存在“原始消息ID:”报头字段表示），接收方处理该数据并生成MDN响应，该响应指示所接收数据的最终处置，并根据RFC 2530[2]和RFC 2532[1]指示可用于未来消息的能力。
If the re-send indicates that alternative data is no longer available (by including an 'Alternative-not-available' disposition notification modifier), and the receiver still holds the original data sent, it should display or process the original data and send an MDN response indicating the final disposition of that data. Thus, the response to an 'Alternative-not-available' indication may be a successful disposition notification.
如果重新发送指示替代数据不再可用（通过包括“替代不可用”处置通知修改器），并且接收方仍保留发送的原始数据，则应显示或处理原始数据，并发送MDN响应，指示该数据的最终处置。因此，对“备选方案不可用”指示的响应可能是成功的处置通知。
If the re-send indicates that alternative data is no longer available (by including an 'Alternative-not-available' disposition notification modifier), and the receiver has discarded the original data sent, it SHOULD:
如果重新发送表明替代数据不再可用（通过包括“替代不可用”处置通知修饰符），并且接收方已丢弃发送的原始数据，则应：
(a) display or process the failure message received, OR
(a) 显示或处理接收到的故障消息，或
(b) construct and display a message indicating that message data has been lost, preferably indicating the sender, time, subject, message identifier and other information that may help the recipient user to identify the missing message.
(b) 构造并显示指示消息数据已丢失的消息，优选地指示发送者、时间、主题、消息标识符和可帮助接收方用户识别丢失消息的其他信息。
and send a message disposition response indicating a final message disposition of "deleted".
并发送消息处置响应，指示“已删除”的最终消息处置。
The 'Content-alternative:' header is a MIME header that can be attached to a MIME body part to indicate availability of some alternative form of the data it contains. This header does not, of itself, indicate how the alternative form of data may be accessed.
“Content alternative:”标头是一个MIME标头，可以附加到MIME主体部分，以指示其包含的某些替代形式的数据的可用性。此标题本身并不表示如何访问替代形式的数据。
Using the ABNF notation of RFC 2234 [10], the syntax of a 'Content-alternative' header is defined as:
使用RFC 2234[10]的ABNF符号，“内容替代”标题的语法定义为：
Content-alternative-header = "Content-alternative" ":" Alternative-feature-expression
Content alternative header=“Content alternative”“：”可选功能表达式
Alternative-feature-expression = <As defined for 'Filter' by RFC 2533 [6]>
替代特征表达式=<如RFC 2533[6]为“过滤器”定义的那样>
More than one 'Content-alternative:' header may be applied to a MIME body part, in which case each one is taken to describe a separate alternative data format that is available.
MIME正文部分可以应用多个“Content alternative:”标题，在这种情况下，每个标题都用来描述一种单独的可用替代数据格式。
A content-alternative header is used with some MIME-encapsulated data, and is interpreted in that context. The intent is to indicate possible variations of that data, and it is not necessarily expected to be a complete free-standing description of a specific available data. Enough information should be provided for a receiver to be able to decide whether or not the alternative thus described (a) is likely to be an improvement over the actual data provided, and (b) is likely to be processable by the receiver.
content alternative标头与一些MIME封装的数据一起使用，并在该上下文中进行解释。其目的是指出该数据的可能变化，不一定是对特定可用数据的完整独立描述。应当为接收器提供足够的信息，以便能够决定这样描述的替代方案（a）是否可能是对所提供的实际数据的改进，以及（b）是否可能由接收器处理。
Thus, when interpreting a Content-alternative header value, a receiver may assume that features not explicitly mentioned are not different in the indicated alternative from the supplied data. For example, if a Content-alternative header does not mention an alternative MIME content-type, the receiver may assume that the available alternative uses the same content-type as the supplied data.
因此，当解释内容替代报头值时，接收器可以假设未明确提及的特征在所指示的替代中与所提供的数据没有不同。例如，如果内容备选标题未提及备选MIME内容类型，则接收方可能假设可用备选内容使用与所提供数据相同的内容类型。
See also the example in section 8.4.
另见第8.4节中的示例。
The 'Original-Message-ID' header is used to correlate any message response or re-send with the original message to which it relates (see also sections 3.2.3, 3.3). A re-send is distinct from the original message, so it MUST have its own unique Message-ID value (per RFC 2822, section 3.6.4).
“原始消息ID”标头用于将任何消息响应或重新发送与其相关的原始消息关联起来（另请参见第3.2.3、3.3节）。重新发送与原始邮件不同，因此它必须有自己的唯一邮件ID值（根据RFC 2822，第3.6.4节）。
The syntax for this header is:
此标头的语法为：
"Original-Message-ID" ":" msg-id
“原始邮件ID”“：”消息ID
where 'msg-id' is defined by RFC 2822 as:
其中，RFC 2822将“msg id”定义为：
msg-id = "<" id-left "@" id-right ">"
msg-id = "<" id-left "@" id-right ">"
The 'msg-id' value given must be identical to that supplied in the Message-ID: header of the original message for which the current message is a response or re-send.
给定的“msg id”值必须与当前消息为响应或重新发送的原始消息的Message id:header中提供的值相同。
Here, we define two extensions to the Message Disposition Notification (MDN) protocol [4] to allow a sender to indicate readiness to send alternative message data formats, and to allow a receiver to indicate a preference for some alternative format.
在这里，我们定义了消息处置通知（MDN）协议[4]的两个扩展，以允许发送方指示已准备好发送替代消息数据格式，并允许接收方指示对某些替代格式的偏好。
Indication of what alternatives may be available or preferred are not covered here. This functionality is provided by the 'Content-alternative' MIME header [8] and "Indicating Supported Media Features Using Extensions to DSN and MDN" [2].
此处未说明可用或首选的替代方案。此功能由“Content alternative”MIME标头[8]和“使用DSN和MDN扩展指示支持的媒体功能”[2]提供。
A sender wishing to indicate its readiness to send alternative message data formats must request an MDN response using the MDN 'Disposition-Notification-To:' header [4].
希望表明其已准备好发送替代消息数据格式的发送方必须使用MDN“处置通知至：”标头[4]请求MDN响应。
The MDN request is accompanied by a 'Disposition-Notification-Options:' header containing the parameter 'Alternative-available' with an importance value of 'optional'. (The significance of 'optional' is that receiving agents unaware of this option do not generate inappropriate failure responses.)
MDN请求附带一个“处置通知选项：”标题，其中包含参数“可选可用”，重要性值为“可选”。（可选的意义在于，不知道该选项的接收代理不会生成不适当的故障响应。）
This specification defines a value for 'attribute' to be used in an MDN 'Disposition-Notification-Options:' header [4]:
此规范定义了要在MDN处置通知选项中使用的“属性”的值：“标头[4]：
attribute =/ "Alternative-available"
属性=/“备选方案可用”
Thus, a sender includes the following headers to indicate that alternative message data is available:
因此，发送方包括以下标头，以指示替代消息数据可用：
Disposition-Notification-To:
<sender-address>
Disposition-Notification-Options:
Alternative-available=optional,<lifetime>
Disposition-Notification-To:
<sender-address>
Disposition-Notification-Options:
Alternative-available=optional,<lifetime>
where <lifetime> is "transient" or "permanent", indicating whether the alternative data will be made available for just a short while, or for an indefinite period. A value of "permanent" indicates that the data is held on long term storage and can be expected to be available for at least several days, and probably weeks or months. A value of "transient" indicates that the alternative data may be discarded at any time, though it would normally be held for the expected duration of a message transaction.
其中，<life>是“暂时的”还是“永久的”，表示替代数据是短期可用，还是无限期可用。值“permanent”表示数据保存在长期存储中，预计至少可以使用几天，可能是几周或几个月。值“transient”表示可随时丢弃替代数据，尽管它通常会在消息事务的预期持续时间内保留。
NOTE: the <lifetime> parameter is provided to help low-memory receivers (which are unable to store received data) avoid loss of information through requesting an alternative data format that may become unavailable.
注意：<lifetime>参数用于帮助内存不足的接收器（无法存储接收到的数据）通过请求可能变得不可用的替代数据格式来避免信息丢失。
A message sent with a request for an MDN with an 'Alternative-available' option MUST also contain a 'Message-ID:' header field [20].
通过“可选可用”选项请求MDN发送的消息还必须包含“消息ID:”标题字段[20]。
The MDN specification [4] defines a number of message disposition options that may be reported by the receiver of a message:
MDN规范[4]定义了许多消息处理选项，这些选项可由消息接收方报告：
disposition-type = "displayed"
/ "dispatched"
/ "processed"
/ "deleted"
/ "denied"
/ "failed"
disposition-type = "displayed"
/ "dispatched"
/ "processed"
/ "deleted"
/ "denied"
/ "failed"
disposition-modifier = ( "error" / "warning" )
/ ( "superseded" / "expired" /
"mailbox-terminated" )
/ disposition-modifier-extension
disposition-modifier = ( "error" / "warning" )
/ ( "superseded" / "expired" /
"mailbox-terminated" )
/ disposition-modifier-extension
This specification defines an additional value for 'disposition-modifier-extension':
本规范为“处置修改器扩展名”定义了一个附加值：
disposition-modifier-extension =/ "Alternative-preferred"
处置修改器扩展=/“首选备选方案”
When a receiver requests that an alternative format be sent, it sends a message disposition notification message containing the following disposition field:
当接收方请求发送替代格式时，它会发送一条包含以下处置字段的消息处置通知消息：
Disposition:
<action-mode>/<sending-mode>,
deleted/alternative-preferred
Disposition:
<action-mode>/<sending-mode>,
deleted/alternative-preferred
For example, an automatically generated response might contain:
例如，自动生成的响应可能包含：
Disposition: automatic-action/MDN-sent-automatically, deleted/alternative-preferred
处置：自动操作/MDN自动发送，删除/首选备选方案
An MDN response containing an 'alternative-preferred' disposition modifier MUST also contain an 'Original-message-ID:' field [4] with the 'Message-ID:' value from the original message.
包含“可选首选”处置修饰符的MDN响应还必须包含具有原始消息中“消息ID:”值的“原始消息ID:”字段[4]。
An MDN response containing an 'alternative-preferred' disposition modifier SHOULD also contain a 'Media-accept-features:' field [2] indicating the capabilities that the sender should use in selecting an alternative form of message data. If this field is not supplied, the sender should assume some baseline feature capabilities. Receiver capabilities supplied with an alternative-preferred disposition notification MUST NOT be cached: they may apply to the current transaction only.
包含“alternative preferred”处置修饰符的MDN响应还应包含“Media accept features:”字段[2]，指示发件人在选择消息数据的替代形式时应使用的功能。如果未提供此字段，则发送方应假定某些基线功能。不得缓存随备选首选处置通知提供的接收方功能：它们可能仅适用于当前事务。
A sender that receives a request for alternative data that is no longer available, or is unable to provide alternative data matching the receiver's capabilities, MUST respond with an indication of this fact, sending a message containing data describing the failure.
收到不再可用的替代数据请求的发送方，或无法提供与接收方能力匹配的替代数据的发送方，必须响应此事实的指示，发送包含描述故障的数据的消息。
Such a message MUST specify the MDN 'Disposition-Notification-To:' header [4], accompanied by a 'Disposition-Notification-Options:' header containing the parameter 'Alternative-not-available' with an importance value of 'required'.
此类消息必须指定MDN“Disposition Notification To:”标头[4]，并附带一个“Disposition Notification Options:”标头，其中包含参数“Alternative not available”，重要性值为“required”。
This specification defines a value for 'attribute' to be used in an MDN 'Disposition-Notification-Options:' header [4]:
此规范定义了要在MDN处置通知选项中使用的“属性”的值：“标头[4]：
attribute =/ "Alternative-not-available"
属性=/“备选方案不可用”
Thus, a sender includes the following headers to indicate that the alternative message data previously offered is no longer available:
因此，发送方包括以下标头，以指示先前提供的替代消息数据不再可用：
Disposition-Notification-To:
<sender-address>
Disposition-Notification-Options:
Alternative-not-available=required,(TRUE)
Disposition-Notification-To:
<sender-address>
Disposition-Notification-Options:
Alternative-not-available=required,(TRUE)
A message sent with a request for an MDN with an 'Alternative-not-available' option MUST also contain an 'Original-message-ID:' header [23] containing the value from the 'Message-ID:' header of the original message.
带有“Alternative not available”（备选方案不可用）选项的MDN请求发送的邮件还必须包含“原始邮件ID:”标头[23]，其中包含原始邮件的“邮件ID:”标头中的值。
This specification defines an additional value for 'disposition-modifier-extension':
本规范为“处置修改器扩展名”定义了一个附加值：
disposition-modifier-extension =/ "original-lost"
处置修改器扩展=/“原始丢失”
When a receiver loses message data because it lacks memory to store the original while waiting for an alternative to be sent, it sends a message disposition notification containing the following field:
当接收者在等待发送备选方案时由于缺少存储原始信息的内存而丢失消息数据时，它将发送包含以下字段的消息处置通知：
Disposition:
<action-mode>/<sending-mode>,
deleted/original-lost
Disposition:
<action-mode>/<sending-mode>,
deleted/original-lost
For example, an automatically generated response might contain:
例如，自动生成的响应可能包含：
Disposition: automatic-action/MDN-sent-automatically, deleted/original-lost
处置：自动操作/MDN自动发送、删除/原始丢失
An MDN response containing an 'original-lost' disposition modifier MUST also contain an 'Original-message-ID:' field [4] with the 'Message-ID:' value from the resent message, or from the original message (if no re-send has been received).
包含“原始丢失”处置修饰符的MDN响应还必须包含“原始消息ID:”字段[4]，该字段具有来自重新发送消息或原始消息（如果未收到重新发送）的“消息ID:”值。
In sending an MDN response that requests alternative data, the security concerns stated in RFC 2298 [4] (sections 2.1 and 6.2) regarding automatic MDN responses must be respected. In particular, a system capable of performing content negotiation MUST have an option for its user to disable negotiation responses, either generally, on a per-message basis, or both.
在发送请求替代数据的MDN响应时，必须遵守RFC 2298[4]（第2.1节和第6.2节）中关于自动MDN响应的安全问题。特别是，能够执行内容协商的系统必须为其用户提供一个选项来禁用协商响应，通常是基于每条消息，或者两者都禁用。
Internet fax is an application that uses email to exchange document images (see RFC RFC 2305 [12] and RFC 2532 [1]).
Internet传真是一种使用电子邮件交换文档图像的应用程序（请参阅RFC RFC 2305[12]和RFC 2532[1]）。
Both sender and receiver parts of this specification involve the use of media feature expressions. In the context of Internet fax, any such expressions SHOULD employ feature tags defined by "Content feature schema for Internet fax" [16]. In a wider email context, any valid media features MAY be used.
本规范的发送方和接收方部分均涉及媒体功能表达式的使用。在互联网传真的上下文中，任何此类表达式都应使用“互联网传真的内容特征模式”[16]定义的特征标记。在更广泛的电子邮件环境中，可以使用任何有效的媒体功能。
For Internet fax [12], "image/tiff" is the assumed content-type for message data. In particular, all Internet fax devices are presumed to be capable of sending and receiving the TIFF profile S capabilities (Section 3 of [11]). When communication is between Internet fax devices, this capability may be assumed. But when dealing with devices that go beyond these capabilities defined for Internet fax (e.g. generic email agents with fax capabilities) it would be better not to assume fax capabilities, and for the negotiating parties to be explicit with respect to all their capabilities.
对于Internet传真[12]，“图像/tiff”是消息数据的假定内容类型。特别是，假定所有互联网传真设备都能够发送和接收TIFF配置文件的功能（见[11]第3节）。当在因特网传真设备之间进行通信时，可以假定这种能力。但是，当处理的设备超出了为Internet传真定义的这些功能时（例如，具有传真功能的通用电子邮件代理），最好不要假设传真功能，并且谈判方应明确其所有功能。
It would be better if even Internet fax devices do not assume that they are communicating with other such devices. When using Internet email, there is no reliable way to establish this fact. Therefore, for any Internet fax device that may reasonably be expected to exchange messages with any other email agent, it is RECOMMENDED that Internet fax capabilities (such as image/tiff baseline format handling) are not assumed but stated explicitly.
如果即使是互联网传真设备也不认为它们正在与其他此类设备通信，那就更好了。当使用互联网电子邮件时，没有可靠的方法来证实这一事实。因此，对于可能合理预期与任何其他电子邮件代理交换消息的任何互联网传真设备，建议不要假设而是明确说明互联网传真功能（如图像/tiff基线格式处理）。
In particular, the 'Media-Accept-Features:' header in receiver MDN responses SHOULD explicitly indicate (type="image/tiff") and baseline TIFF capabilities, rather than just assuming that they are understood.
特别是，接收器MDN响应中的“媒体接受功能：”标题应明确指出（type=“image/tiff”）和基线tiff功能，而不仅仅是假设它们已被理解。
An Internet fax sender has a profile-F (A4, 400x400dpi, MMR) image to send to a receiver. The baseline for Internet fax is 200x200dpi and MH image compression.
Internet传真发送方有一个profile-F（A4，400x400dpi，MMR）图像要发送给接收方。Internet传真的基准是200x200dpi和MH图像压缩。
Sender's initial message:
发件人的初始邮件：
Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Content Negotiation
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Content Negotiation
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
--RAA14128.773615765/ example.com Content-type: image/tiff Content-Transfer-Encoding: base64 Content-features: (& (color=Binary) (image-file-structure=TIFF-minimal) (dpi=200) (dpi-xyratio=1) (paper-size=A4) (image-coding=MH) (MRC-mode=0) (ua-media=stationery) ) Content-alternative: (& (color=Binary) (image-file-structure=TIFF-limited) (dpi=400) (dpi-xyratio=1) (paper-size=A4) (image-coding=MMR) (MRC-mode=0) (ua-media=stationery) )
--RAA14128.773615765/example.com内容类型：图像/tiff内容传输编码：base64内容特征：（&（颜色=二进制）（图像文件结构=tiff最小值）（dpi=200）（dpi xyratio=1）（纸张大小=A4）（图像编码=MH）（MRC模式=0）（ua媒体=信纸））内容备选方案：（&（颜色=二进制）（图像文件结构=tiff有限）（dpi=400）（dpi xyratio=1）（纸张尺寸=A4）（图像编码=MMR）（MRC模式=0）（ua媒体=信纸））
[TIFF-FX Profile-S message goes here]
[TIFF-FX Profile-S信息如下]
--RAA14128.773615765/ example.com--
--RAA14128.773615765/example.com--
Receiver sends MDN response to initial message:
接收方向初始消息发送MDN响应：
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200020.12345@example.org>
Subject: Re: Internet FAX Full Mode Content Negotiation
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615766/example.org"
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200020.12345@example.org>
Subject: Re: Internet FAX Full Mode Content Negotiation
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615766/example.org"
--RAA14128.773615766/example.org
--RAA14128.773615766/example.org
The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to Tom Recipient <Tom_Recipient@example.org> with subject "Internet FAX Full Mode Content Negotiation" has been received. An alternative form of the message data is requested.
该邮件于1995年9月20日00:18:00（美国东部夏令时）-0400发送给Tom收件人<Tom_Recipient@example.org>已收到主题为“互联网传真完整模式内容协商”的邮件。请求另一种形式的消息数据。
--RAA14128.773615766/example.org Content-Type: message/disposition-notification
--RAA14128.773615766/example.org内容类型：消息/处置通知
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200019.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically;
deleted/alternative-preferred
Media-Accept-Features:
(& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF)
(| (& (dpi=200) (dpi-xyratio=200/100) )
(& (dpi=200) (dpi-xyratio=1) )
(& (dpi=400) (dpi-xyratio=1) ) )
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(MRC-mode=0)
(paper-size=[A4,B4])
(ua-media=stationery) )
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200019.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically;
deleted/alternative-preferred
Media-Accept-Features:
(& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF)
(| (& (dpi=200) (dpi-xyratio=200/100) )
(& (dpi=200) (dpi-xyratio=1) )
(& (dpi=400) (dpi-xyratio=1) ) )
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(MRC-mode=0)
(paper-size=[A4,B4])
(ua-media=stationery) )
--RAA14128.773615766/example.org--
--RAA14128.773615766/example.org--
Sender's message with enhanced content:
具有增强内容的发件人邮件：
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200021.12345@example.com>
Original-Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Image Transmission
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615768/ example.com"
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200021.12345@example.com>
Original-Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Image Transmission
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615768/ example.com"
--RAA14128.773615768/ example.com Content-type: image/tiff Content-Transfer-Encoding: base64
--RAA14128.773615768/example.com内容类型：image/tiff内容传输编码：base64
[TIFF-FX profile-F message goes here]
[TIFF-FX profile-F信息在此显示]
--RAA14128.773615768/ example.com--
--RAA14128.773615768/example.com--
Receiver sends MDN confirmation of enhanced message content:
接收方发送增强消息内容的MDN确认：
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
--RAA14128.773615769/example.org
--RAA14128.773615769/example.org
The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom Recipient <Tom_Recipient@example.org> with subject " Internet FAX Full Mode Image Transmission" has been processed in Internet FAX Full Mode.
该邮件于1995年9月20日00:21:00（美国东部夏令时）-0400发送给Tom收件人<Tom_Recipient@example.org>主题“Internet传真全模式图像传输”已在Internet传真全模式下处理。
--RAA14128.773615769/example.org Content-Type: message/disposition-notification
--RAA14128.773615769/example.org内容类型：消息/处置通知
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-Features:
(& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF)
(| (& (dpi=200) (dpi-xyratio=200/100) )
(& (dpi=200) (dpi-xyratio=1) )
(& (dpi=400) (dpi-xyratio=1) ) )
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(MRC-mode=0)
(paper-size=[A4,B4])
(ua-media=stationery) )
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-Features:
(& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF)
(| (& (dpi=200) (dpi-xyratio=200/100) )
(& (dpi=200) (dpi-xyratio=1) )
(& (dpi=400) (dpi-xyratio=1) ) )
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(MRC-mode=0)
(paper-size=[A4,B4])
(ua-media=stationery) )
--RAA14128.773615769/example.org--
--RAA14128.773615769/example.org--
This example shows how the second and subsequent transfers between the systems in the previous example might be conducted. Using knowledge gained from the previous exchange, the sender includes profile-F data with its first contact.
此示例显示了如何在前一示例中的系统之间执行第二次和后续传输。使用从先前交换中获得的知识，发送方将profile-F数据包含在其第一个联系人中。
Sender's initial message:
发件人的初始邮件：
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Content Negotiation
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Content Negotiation
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
--RAA14128.773615765/ example.com Content-type: image/tiff Content-Transfer-Encoding: base64 Content-features: (& (color=Binary) (image-file-structure=TIFF-limited) (dpi=400) (dpi-xyratio=1) (paper-size=A4) (image-coding=MMR) (MRC-mode=0) (ua-media=stationery) ) Content-alternative: (& (color=Binary) (image-file-structure=TIFF-minimal) (dpi=200) (dpi-xyratio=1) (paper-size=A4) (image-coding=MH) (MRC-mode=0) (ua-media=stationery) )
--RAA14128.773615765/example.com内容类型：图像/tiff内容传输编码：base64内容特征：（&（颜色=二进制）（图像文件结构=tiff有限）（dpi=400）（dpi xyratio=1）（纸张大小=A4）（图像编码=MMR）（MRC模式=0）（ua媒体=信纸））内容备选方案：（&（颜色=二进制）（图像文件结构=tiff最小）（dpi=200）（dpi xyratio=1）（纸张尺寸=A4）（图像编码=MH）（MRC模式=0）（ua媒体=信纸））
[TIFF-FX Profile-F message goes here]
[TIFF-FX Profile-F信息在此显示]
--RAA14128.773615765/ example.com--
--RAA14128.773615765/example.com--
Receiver sends MDN confirmation of received message content:
接收方发送接收到的消息内容的MDN确认：
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
--RAA14128.773615769/example.org
--RAA14128.773615769/example.org
The message sent on 1995 Sep 20 at 00:19:00 (EDT) -0400 to Tom Recipient <Tom_Recipient@example.org> with subject "Internet FAX Full Mode Image Transmission" has been processed in Internet FAX Full Mode.
该邮件于1995年9月20日00:19:00（美国东部夏令时）-0400发送给Tom收件人<Tom_Recipient@example.org>主题“Internet传真全模式图像传输”已在Internet传真全模式下处理。
--RAA14128.773615769/example.org Content-Type: message/disposition-notification
--RAA14128.773615769/example.org内容类型：消息/处置通知
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-Features:
(& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF)
(| (& (dpi=200) (dpi-xyratio=200/100) )
(& (dpi=200) (dpi-xyratio=1) )
(& (dpi=400) (dpi-xyratio=1) ) )
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(MRC-mode=0)
(paper-size=[A4,B4])
(ua-media=stationery) )
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-Features:
(& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF)
(| (& (dpi=200) (dpi-xyratio=200/100) )
(& (dpi=200) (dpi-xyratio=1) )
(& (dpi=400) (dpi-xyratio=1) ) )
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(MRC-mode=0)
(paper-size=[A4,B4])
(ua-media=stationery) )
--RAA14128.773615769/example.org--
--RAA14128.773615769/example.org--
In this example, the sender has incorrectly assumed that the receiver has a higher capability, and must re-send lower capability data in response to the receiver's response showing lesser capability.
在此示例中，发送方错误地假设接收方具有更高的容量，并且必须重新发送较低容量的数据，以响应接收方显示出较小容量的响应。
An Internet fax sends a profile-F (A4, 400x400dpi, MMR) image. When the receiver cannot handle this, it falls back to baseline profile-S. As this is a baseline format, it is not necessary to declare that capability with the original message. When a receiver is faced with data it cannot process from a negotiating sender, it can do no better than to respond with a description of its actual capabilities and let the sender determine the outcome.
Internet传真发送一个profile-F（A4，400x400dpi，MMR）图像。当接收方无法处理此问题时，它会返回到基线概要文件-S。由于这是一种基线格式，因此无需在原始消息中声明该功能。当接收者面对无法处理来自协商发送者的数据时，它只能用对其实际能力的描述作出响应，并让发送者确定结果。
Sender's initial message:
发件人的初始邮件：
Date: Wed, 20 Sep 1995 00:18:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Negotiate Down
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
Date: Wed, 20 Sep 1995 00:18:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Negotiate Down
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
--RAA14128.773615765/ example.com Content-type: image/tiff Content-Transfer-Encoding: base64 Content-features: (& (color=Binary) (image-file-structure=TIFF-limited) (dpi=400) (dpi-xyratio=1) (paper-size=A4) (image-coding=MMR) (MRC-mode=0) (ua-media=stationery) )
--RAA14128.773615765/example.com内容类型：图像/tiff内容传输编码：base64内容特征：（&（颜色=二进制）（图像文件结构=tiff有限）（dpi=400）（dpi xyratio=1）（纸张大小=A4）（图像编码=MMR）（MRC模式=0）（ua媒体=信纸））
[TIFF-FX Profile-F message goes here]
[TIFF-FX Profile-F信息在此显示]
--RAA14128.773615765/ example.com--
--RAA14128.773615765/example.com--
Receiver sends MDN response to initial message:
接收方向初始消息发送MDN响应：
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200020.12345@example.org>
Subject: Re: Internet FAX Full Mode Negotiate Down
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615766/example.org"
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200020.12345@example.org>
Subject: Re: Internet FAX Full Mode Negotiate Down
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615766/example.org"
--RAA14128.773615766/example.org
--RAA14128.773615766/example.org
The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to Tom Recipient <Tom_Recipient@example.org> with subject "Internet FAX Full Mode Content Negotiation" has been received. An alternative form of the message data is requested.
该邮件于1995年9月20日00:18:00（美国东部夏令时）-0400发送给Tom收件人<Tom_Recipient@example.org>已收到主题为“互联网传真完整模式内容协商”的邮件。请求另一种形式的消息数据。
--RAA14128.773615766/example.org Content-Type: message/disposition-notification
--RAA14128.773615766/example.org内容类型：消息/处置通知
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200019.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically;
deleted/alternative-preferred
Media-Accept-Features:
(& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MH)
(MRC-mode=0)
(ua-media=stationery) )
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200019.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically;
deleted/alternative-preferred
Media-Accept-Features:
(& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MH)
(MRC-mode=0)
(ua-media=stationery) )
--RAA14128.773615766/example.org--
--RAA14128.773615766/example.org--
Sender's message with baseline content:
发件人的邮件包含基线内容：
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200021.12345@example.com>
Original-Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Image Transmission
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615768/ example.com"
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200021.12345@example.com>
Original-Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Image Transmission
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615768/ example.com"
--RAA14128.773615768/ example.com Content-type: image/tiff Content-Transfer-Encoding: base64
--RAA14128.773615768/example.com内容类型：image/tiff内容传输编码：base64
[TIFF-FX profile-S message goes here]
[TIFF-FX profile-S信息如下]
--RAA14128.773615768/ example.com--
--RAA14128.773615768/example.com--
Receiver sends MDN confirmation of impoverished message content:
接收方发送贫消息内容的MDN确认：
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
--RAA14128.773615769/example.org
--RAA14128.773615769/example.org
The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom Recipient <Tom_Recipient@example.org> with subject " Internet FAX Full Mode Image Transmission" has been processed in Internet FAX Full Mode.
该邮件于1995年9月20日00:21:00（美国东部夏令时）-0400发送给Tom收件人<Tom_Recipient@example.org>主题“Internet传真全模式图像传输”已在Internet传真全模式下处理。
--RAA14128.773615769/example.org Content-Type: message/disposition-notification
--RAA14128.773615769/example.org内容类型：消息/处置通知
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-Features:
(& (color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MH)
(MRC-mode=0)
(ua-media=stationery) )
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-Features:
(& (color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MH)
(MRC-mode=0)
(ua-media=stationery) )
--RAA14128.773615769/example.org--
--RAA14128.773615769/example.org--
As noted in section 4, the sender can offer the data using a different MIME content-type. This example shows a profile-F (A4, 400x400dpi, MMR) image and a limited-colour PDF document offered as alternatives to a baseline image/TIFF.
如第4节所述，发送方可以使用不同的MIME内容类型提供数据。此示例显示了一个profile-F（A4、400x400dpi、MMR）图像和一个作为基线图像/TIFF的备选方案提供的有限颜色PDF文档。
Sender's initial message:
发件人的初始邮件：
(Note that the MIME content type is not specified for the image/tiff alternative, being the same as that provided, but is mentioned for the application/pdf alternative.)
（请注意，没有为image/tiff备选方案指定MIME内容类型，与提供的相同，但为application/pdf备选方案指定了MIME内容类型。）
Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Content Negotiation
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Content Negotiation
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
--RAA14128.773615765/ example.com Content-type: image/tiff Content-Transfer-Encoding: base64 Content-features: (& (color=Binary) (image-file-structure=TIFF-minimal)
--RAA14128.773615765/example.com内容类型：图像/tiff内容传输编码：base64内容功能：（&（颜色=二进制）（图像文件结构=tiff最小值）
(dpi=200) (dpi-xyratio=1) (paper-size=A4) (image-coding=MH) (MRC-mode=0) (ua-media=stationery) ) Content-alternative: (& (color=Binary) (image-file-structure=TIFF-limited) (dpi=400) (dpi-xyratio=1) (paper-size=A4) (image-coding=MMR) (MRC-mode=0) (ua-media=stationery) ) Content-alternative: (& (type="application/pdf") (color=Limited) (dpi=400) (paper-size=A4) (ua-media=stationery) )
（dpi=200）（dpi xyratio=1）（纸张尺寸=A4）（图像编码=MH）（MRC模式=0）（ua媒体=信纸））内容备选方案：（&（颜色=二进制）（图像文件结构=TIFF有限）（dpi=400）（纸张尺寸=A4）（图像编码=MMR）（MRC模式=0）（ua媒体=信纸））内容备选方案：（&（类型=“应用程序/pdf”）（颜色=有限）（dpi=400）（纸张尺寸=A4）（ua介质=信纸）
[TIFF-FX Profile-S message goes here]
[TIFF-FX Profile-S信息如下]
--RAA14128.773615765/ example.com--
--RAA14128.773615765/example.com--
Receiver sends MDN response to initial message:
接收方向初始消息发送MDN响应：
(Note that this response indicates an ability to handle the PDF MIME content-types, but with only binary colour.)
（请注意，此响应表示能够处理PDF MIME内容类型，但仅使用二进制颜色。）
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200020.12345@example.org>
Subject: Re: Internet FAX Full Mode Content Negotiation
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615766/example.org"
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200020.12345@example.org>
Subject: Re: Internet FAX Full Mode Content Negotiation
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615766/example.org"
--RAA14128.773615766/example.org
--RAA14128.773615766/example.org
The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to Tom Recipient <Tom_Recipient@example.org> with subject "Internet FAX Full Mode Content Negotiation" has been received. An alternative form of the message data is requested.
该邮件于1995年9月20日00:18:00（美国东部夏令时）-0400发送给Tom收件人<Tom_Recipient@example.org>已收到主题为“互联网传真完整模式内容协商”的邮件。请求另一种形式的消息数据。
--RAA14128.773615766/example.org Content-Type: message/disposition-notification
--RAA14128.773615766/example.org内容类型：消息/处置通知
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200019.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically;
deleted/alternative-preferred
Media-Accept-Features:
(| (& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(image-coding=MH)
(MRC-mode=0)
(paper-size=A4)
(ua-media=stationery) )
(& (type="application/pdf")
(color=Binary)
(dpi-xyratio=1)
(dpi=[200,400])
(paper-size=[A4,B4])
(ua-media=stationery) ) )
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200019.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically;
deleted/alternative-preferred
Media-Accept-Features:
(| (& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(image-coding=MH)
(MRC-mode=0)
(paper-size=A4)
(ua-media=stationery) )
(& (type="application/pdf")
(color=Binary)
(dpi-xyratio=1)
(dpi=[200,400])
(paper-size=[A4,B4])
(ua-media=stationery) ) )
--RAA14128.773615766/example.org--
--RAA14128.773615766/example.org--
Resend with alternative content-type:
使用替代内容类型重新发送：
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200021.12345@example.com>
Original-Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Image Transmission
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615768/ example.com"
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200021.12345@example.com>
Original-Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Image Transmission
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615768/ example.com"
--RAA14128.773615768/ example.com Content-type: application/pdf Content-Transfer-Encoding: base64
--RAA14128.773615768/example.com内容类型：应用程序/pdf内容传输编码：base64
[PDF data goes here]
[PDF数据在此显示]
--RAA14128.773615768/ example.com--
--RAA14128.773615768/example.com--
Receiver sends MDN confirmation of enhanced message content:
接收方发送增强消息内容的MDN确认：
(Also indicating the PDF capability for future messages.)
（还指示未来邮件的PDF功能。）
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
--RAA14128.773615769/example.org
--RAA14128.773615769/example.org
The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom Recipient <Tom_Recipient@example.org> with subject " Internet FAX Full Mode Image Transmission" has been processed in Internet FAX Full Mode.
该邮件于1995年9月20日00:21:00（美国东部夏令时）-0400发送给Tom收件人<Tom_Recipient@example.org>主题“Internet传真全模式图像传输”已在Internet传真全模式下处理。
--RAA14128.773615769/example.org Content-Type: message/disposition-notification
--RAA14128.773615769/example.org内容类型：消息/处置通知
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-Features:
(| (& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(image-coding=MH)
(MRC-mode=0)
(paper-size=A4)
(ua-media=stationery) )
(& (type="application/pdf")
(color=Binary)
(dpi-xyratio=1)
(dpi=[200,400])
(paper-size=[A4,B4])
(ua-media=stationery) ) )
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-Features:
(| (& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(image-coding=MH)
(MRC-mode=0)
(paper-size=A4)
(ua-media=stationery) )
(& (type="application/pdf")
(color=Binary)
(dpi-xyratio=1)
(dpi=[200,400])
(paper-size=[A4,B4])
(ua-media=stationery) ) )
--RAA14128.773615769/example.org--
--RAA14128.773615769/example.org--
This specification defines new email/MIME message headers:
本规范定义了新的电子邮件/MIME消息头：
Content-alternative Original-Message-ID
内容替代原始消息ID
As such, there being no registry of email headers, it is an update to the specifications of RFC 2822 and RFC 2045.
因此，没有电子邮件头的注册，这是对RFC 2822和RFC 2045规范的更新。
This specification defines extensions to the Message Disposition Notification (MDN) protocol. The sections below are the registration templates for these extensions, as required by RFC 2298 [4], section 10.
本规范定义了消息处置通知（MDN）协议的扩展。以下各节是RFC 2298[4]第10节要求的这些扩展的注册模板。
(a) Disposition-notification-option name: Alternative-available
(a) 处置通知选项名称：可选
(b) Syntax: (see this document, section 6.1)
(b) 语法：（见本文件第6.1节）
(c) Character-encoding: US-ASCII characters only are used
(c) 字符编码：仅使用US-ASCII字符
(d) Semantics: (see this document, section 6.1)
(d) 语义：（见本文件第6.1节）
(a) Disposition-notification-option name: Alternative-not-available
(a) 处置通知选项名称：备选方案不可用
(b) Syntax: (see this document, section 6.1)
(b) 语法：（见本文件第6.1节）
(c) Character-encoding: US-ASCII characters only are used
(c) 字符编码：仅使用US-ASCII字符
(d) Semantics (see this document, section 6.3)
(d) 语义（见本文件第6.3节）
(a) Disposition-modifier name: Alternative-preferred
(a) 处置修改器名称：首选备选方案
(b) Semantics: (see this document, section 6.2)
(b) 语义：（见本文件第6.2节）
(a) Disposition-modifier name: Original-lost
(a) 处置修改器名称：原始丢失
(b) Semantics: (see this document, section 6.4)
(b) 语义：（见本文件第6.4节）
This specification deals with protocol exchanges between mail user agents, and as such does not deal primarily with human readable text. But not all user agents may automatically handle the protocol elements defined here, and may attempt to display text from the protocol elements to the user.
本规范处理邮件用户代理之间的协议交换，因此主要不处理人类可读的文本。但并非所有用户代理都可以自动处理此处定义的协议元素，并且可能尝试向用户显示协议元素中的文本。
The main candidate for this treatment is the text accompanying a disposition notification response that requests alternative information. In normal use, the protocol design ensures that the recipient can process this response automatically; exceptionally, a receiving agent may display it to a user.
这种处理方法的主要候选文本是请求替代信息的处置通知响应附带的文本。在正常使用中，协议设计确保接收方能够自动处理该响应；例外情况下，接收代理可以将其显示给用户。
Security considerations of this specification can be divided into two main areas:
本规范的安全注意事项可分为两个主要方面：
o Privacy concerns with automated MDN response generation: see section 6.5 of this document, and the security considerations section of RFC 2298 [4].
o 自动生成MDN响应的隐私问题：见本文件第6.5节和RFC 2298[4]的安全注意事项部分。
o Risks of negotiation: see the security considerations section transaction. If alternative data arrives subsequently, it may be ignored or possibly also displayed or printed. A successful completion MDN may be sent to the sender.
o 谈判风险：见交易安全注意事项一节。如果备选数据随后到达，则可能会忽略该数据，也可能会显示或打印该数据。可以将成功完成的MDN发送给发送方。
The basic structure of the negotiation described here was first documented in a draft by Mr. Toru Maeda of Canon.
这里描述的谈判的基本结构首先由佳能的Toru Maeda先生在草案中记录。
Helpful comments on earlier drafts were provided by Mr Hiroshi Tamura, Ted Hardie and Larry Masinter.
田村弘先生、泰德·哈迪和拉里·马辛特对早期草案提出了有益的意见。
[1] Masinter, L. and D. Wing, "Extended Facsimile using Internet Mail", RFC 2532, March 1999.
[1] Masinter，L.和D.Wing，“使用互联网邮件的扩展传真”，RFC 25321999年3月。
[2] Wing, D., "Indicating Supported Media Features Using Extensions to DSN and MDN", RFC 2530, March 1999.
[2] Wing，D.，“使用DSN和MDN的扩展指示支持的媒体功能”，RFC2530，1999年3月。
[3] Masinter, L., "Terminology and Goals for Internet Fax", RFC 2542, March 1999.
[3] Masinter，L.，“因特网传真的术语和目标”，RFC 25421999年3月。
[4] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998.
[4] Fajman，R.，“用于消息处置通知的可扩展消息格式”，RFC 2298，1998年3月。
[5] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag Registration Procedure", RFC 2506, March 1999.
[5] Holtman，K.，Mutz，A.和T.Hardie，“媒体功能标签注册程序”，RFC 2506，1999年3月。
[6] Klyne, G., "A syntax for describing media feature sets", BCP 31, RFC 2533, March 1999.
[6] Klyne，G.“描述媒体功能集的语法”，BCP 31，RFC 2533，1999年3月。
[7] Klyne, G., "Indicating media features for MIME content", RFC 2938, September 2000.
[7] Klyne，G.“为MIME内容指明媒体特征”，RFC 2938，2000年9月。
[8] 'Content-alternative' header (this memo, section 4)
[8] “内容备选”标题（本备忘录第4节）
[9] MDN extension for alternative data (this memo, section 6)
[9] 替代数据的MDN扩展（本备忘录第6节）
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[10] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[11] McIntyre, L., Buckley, R., Venable, D., Zilles, S., Parsons, G. and J. Rafferty, "File format for Internet fax", RFC 2301, March 1998.
[11] McIntyre，L.，Buckley，R.，Venable，D.，Zilles，S.，Parsons，G.和J.Rafferty，“互联网传真的文件格式”，RFC 2301，1998年3月。
[12] Toyoda K., Ohno H., Murai, J. and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 2305, March 1998.
[12] 丰田章男，Ohno H.，Murai，J.和D.Wing，“使用互联网邮件的简单传真模式”，RFC 2305，1998年3月。
[13] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[13] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[14] Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998.
[14] Holtman，K.和A.Mutz，“HTTP中的透明内容协商”，RFC 2295，1998年3月。
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part 2: Media types", RFC 2046, November 1996.
[15] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第2部分：媒体类型”，RFC 20461996年11月。
[16] Klyne, G. and L. McIntyre, "Content feature schema for Internet fax V2", RFC 2879, August 2000.
[16] Klyne，G.和L.McIntyre，“因特网传真V2的内容特征模式”，RFC 28792000年8月。
[17] Klyne, G., "Protocol-independent Content Negotiation Framework", RFC 2703, September 1999.
[17] Klyne，G.，“独立于协议的内容协商框架”，RFC 2703，1999年9月。
[18] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.
[18] Moore，K.，“传递状态通知的SMTP服务扩展”，RFC 18911996年1月。
[19] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[19] 《简单邮件传输协议》，RFC 28212001年4月。
[20] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[20] Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[21] Klyne, G. and D. Crocker, "Timely Delivery for Facsimile Using Internet Mail", Work in Progress.
[21] Klyne，G.和D.Crocker，“使用互联网邮件及时发送传真”，正在进行中。
[22] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[22] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[23] 'Original-Message-ID' header for mail messages (this memo, section 5)
[23] 邮件消息的“原始消息ID”标题（本备忘录第5节）
[24] Klyne, G., "MIME Content Types in Media Feature Expressions", RFC 2913, September 2000.
[24] Klyne，G.“媒体功能表达式中的MIME内容类型”，RFC 29132000年9月。
Appendix A: Implementation issues
附录A：实施问题
This section is not a normative part of this specification. Rather, it discusses some of the issues that were considered during its design in a way that we hope will be useful to implementers.
本节不是本规范的规范性部分。相反，它以一种我们希望对实现者有用的方式讨论了设计过程中考虑的一些问题。
Probably the biggest implication for implementers of this proposal compared with standard mail user agents is the need to maintain some kind of state information at the receiver while content is being negotiated.
与标准邮件用户代理相比，该方案的实施者可能最大的影响是在协商内容时需要在接收者处维护某种状态信息。
By "receiver state", we mean that a receiver needs to remember that it has received an initial message AND that it has requested an alternative form of data. Without this, when a receiver responds with a request for an alternative data format there is a possibility (if the response does not reach the sender) that the message will be silently lost, despite its having been delivered to the receiving MTA.
所谓“接收者状态”，我们的意思是接收者需要记住，它已经收到了一条初始消息，并且它已经请求了另一种形式的数据。如果没有这一点，当接收者响应一个替代数据格式的请求时（如果响应没有到达发送者），消息可能会被悄悄地丢失，尽管消息已经传递到接收MTA。
The matter of maintaining receiver state is particularly germane because of the requirement to allow low-memory systems to participate in the content negotiation. Unlike traditional T.30 facsimile, where the negotiation takes place within the duration of a single connection, an extended time may be taken to complete a negotiation in email. State information must be maintained for all negotiations outstanding at any time, and there is no theoretical upper bound on how many there may be.
由于需要允许低内存系统参与内容协商，因此维护接收器状态的问题尤其密切相关。与传统的T.30传真不同，在单一连接的持续时间内进行协商，在电子邮件中完成协商可能需要较长的时间。任何时候都必须为所有未完成的谈判保留国家信息，并且没有理论上的上限来确定可能有多少谈判。
Keeping receiver state is probably not a problem for systems with high capacity storage devices to hold message data and state information. The remainder of this section discusses strategies that small-system designers might employ to place an upper bound on memory that must be reserved for this information. When a receiver is really memory constrained then message loss remains a possibility, but the mechanisms described here should ensure that it never happens silently.
对于具有高容量存储设备以保存消息数据和状态信息的系统，保持接收器状态可能不是问题。本节的其余部分将讨论小型系统设计人员可能采用的策略，这些策略用于为该信息保留的内存设置上限。当接收者确实受到内存限制时，消息丢失仍然是一种可能性，但是这里描述的机制应该确保它永远不会在静默中发生。
So what is this "receiver state"? It must contain, as a minimum:
那么这个“接收国”是什么呢？它必须至少包含以下内容：
o the fact that message data was received, and alternative data has been requested,
o 收到了消息数据，并请求了替代数据，
o a unique message identifier, and
o 唯一消息标识符，以及
o the time at which an alternative format request was sent.
o 发送替代格式请求的时间。
This allows the receiver to re-issue a request, or to report an error, if requested alternative data does not arrive in a reasonable time.
如果请求的替代数据没有在合理的时间内到达，这允许接收方重新发出请求或报告错误。
Receiver state may also include:
接收国还可以包括：
o a copy of the data originally received. This allows the receiver to display the original data if an alternative is not received.
o 最初收到的数据的副本。这允许接收器在未收到备选方案时显示原始数据。
o details of the data format supplied, and alternatives offered. This permits improved diagnostics if alternative data is not received.
o 提供的数据格式的详细信息，以及提供的备选方案。这允许在未收到替代数据时改进诊断。
If a receiver of a message with alternative content available does not have enough memory to hold new negotiation state information, it may fall back to non-negotiation behaviour, accept the data received and send an MDN indicating disposition of that data (see sections 3.2.1, 3.2.2).
如果具有替代内容的消息的接收者没有足够的内存来保存新的协商状态信息，它可能会退回到非协商行为，接受接收到的数据并发送一个MDN，指示该数据的处置（参见第3.2.1、3.2.2节）。
If a receiving system runs low on memory after entering into a negotiation, a number of options may be possible:
如果接收系统在进入协商后内存不足，则可能会有许多选项：
o display or print buffered data, if available, and complete the transaction. If alternative data arrives subsequently, it may be ignored or possibly also displayed or printed. A successful completion MDN may be sent to the sender.
o 显示或打印缓冲数据（如果可用），并完成事务。如果备选数据随后到达，则可能会忽略该数据，也可能会显示或打印该数据。可以将成功完成的MDN发送给发送方。
o discard any buffered data, and continue waiting for alternative data. If alternative data does not subsequently arrive, a message transfer failure should be declared.
o 丢弃所有缓冲数据，并继续等待替代数据。如果备用数据随后未到达，则应声明消息传输失败。
o abort the transfer and declare a message transfer failure: a diagnostic message must be displayed to the local user, and a failure notification sent to the sender.
o 中止传输并声明消息传输失败：必须向本地用户显示诊断消息，并向发送方发送失败通知。
If a receiver is capable of buffering received message data while waiting for an alternative, this is to be preferred because it retains the option to display that data if an alternative is not received (see above).
如果接收器能够在等待备选方案时缓冲接收到的消息数据，这将是首选，因为它保留了在未接收到备选方案时显示该数据的选项（见上文）。
Partial message data should not be buffered for this purpose: displaying part of the original message is not an allowable substitute for displaying all of the received data. (There may be some value in keeping some of the original message data for diagnostic purposes.)
不应为此目的缓冲部分消息数据：显示部分原始消息不能代替显示所有接收到的数据。（保留一些原始消息数据用于诊断可能有一定的价值。）
If a receiver starts to buffer message data pending negotiation, then finds that the entire message is too large to buffer, it may choose to fall back to "extended mode" and display the incoming data as it is received.
如果接收器开始缓冲待协商的消息数据，然后发现整个消息太大而无法缓冲，它可能会选择退回到“扩展模式”，并在接收时显示传入数据。
When a sender indicates availability of alternative data, it also indicates whether it is permanently or transiently available. The intent of this is that if alternative data is transient, a receiver should not discard original data received. If necessary, it should simply display the original data without requesting an alternative.
当发送方指示替代数据可用时，它还指示该数据是永久可用还是暂时可用。这样做的目的是，如果替代数据是瞬态的，则接收器不应丢弃接收到的原始数据。如有必要，它应仅显示原始数据，而无需请求替代数据。
When a sender indicates that it can offer an alternative format of message content, it accepts some responsibility for trying to ensure that alternative is available if requested. Thus, the message content (both original and any alternative) should be stored for a reasonable period, together with any corresponding Message-ID value(s).
当发送方表示可以提供消息内容的替代格式时，它将承担一定的责任，以确保在请求时提供替代格式。因此，消息内容（原始和任何备选）应与任何相应的消息ID值一起存储一段合理的时间。
A request for retransmission must be accompanied by an Original-Message-ID value that the sender can use to correlate with the message data originally sent.
重新传输请求必须附带原始消息ID值，发送方可以使用该值与最初发送的消息数据关联。
If the sender is operating with a high capacity message storage device (e.g., a disk drive), and normally holds the data for extended periods (several days or weeks) then it should indicate that the alternative data is permanently available (see 6.1): a recipient seeing this may discard the original data, assuming that the sender will most likely be able to re-transmit.
如果发送方使用大容量邮件存储设备（如磁盘驱动器）运行，并且通常会将数据保存较长时间（几天或几周），则应表明替代数据永久可用（见6.1）：收件人看到此情况可能会丢弃原始数据，假设发送方最有可能重新传输。
If the sender has limited memory capacity, and is likely to be able to hold the data for no more than a few minutes or hours, it should indicate that the alternative data is transiently available (see 6.1). If there is doubt about a sender's ability to keep the message content, it should indicate that availability of any alternative is transient.
如果发送方的内存容量有限，并且可能能够保存数据不超过几分钟或几小时，则应表明替代数据暂时可用（见6.1）。如果对发件人保留邮件内容的能力存在疑问，则应表明任何替代方案的可用性都是暂时的。
It should not be assumed that receiver capabilities declared during negotiation are available indefinitely.
不应假设在协商期间声明的接收器功能无限期可用。
In particular, any receiver capabilities declared on a final message confirmation should be regarded as definitive, even if they differ from the capabilities associated with the message just accepted. These may be stored for future use.
特别是，在最终消息确认中声明的任何接收器功能都应被视为确定的，即使它们与刚刚接受的消息相关联的功能不同。这些可能会储存起来供将来使用。
Any receiver capabilities declared when requesting an alternative format should not be stored for future use, as the receiver might be selective about the purposes for which those capabilities may be used.
请求替代格式时声明的任何接收器功能都不应存储以供将来使用，因为接收器可能会选择使用这些功能的目的。
Some of the issues of sender state maintenance may be simplified if content negotiation is used in conjunction with a facility for timely delivery (e.g., [21]). If there is a known time window within which a response should be received, the sender may be less conservative about keeping information about outstanding offers of alternative data for extended periods. A sender that exploits timely delivery in this way should indicate that the alternative is transiently available.
如果将内容协商与及时交付的工具结合使用（例如，[21]），则发送方状态维护的一些问题可能会简化。如果存在一个已知的时间窗口，在该时间窗口内应接收到响应，则发送方在保存关于未完成的替代数据提供的信息以延长期限方面可能不那么保守。以这种方式利用及时交付的发送者应该指出替代方案是暂时可用的。
Ephemeral capabilities may present some special problems. Consider the case of selection of a particular content variant that may depend on an ephemeral setting.
短暂的能力可能会带来一些特殊问题。考虑选择可能依赖于短暂设置的特定内容变体的情况。
Imagine someone sending a basic fax to a color fax machine, indicating that a color alternative is available. The color fax discards the content and sends an MDN which says "deleted/alternative-preferred" to the originator. It then runs out of colored ink. The originating fax then sends a new message which the colored fax cannot print.
想象一下，有人向彩色传真机发送一份基本传真，表明有一种颜色可供选择。彩色传真会丢弃内容，并向发起者发送一个MDN，上面写着“已删除/首选备选方案”。然后，彩色墨水用完了。然后，原始传真发送彩色传真无法打印的新消息。
Or consider an the email client in a phone with sound on/off as a related problem. When sound is ON, the phone may be able to accept voice messages by email.
或者考虑电话中的电子邮件客户端作为一个相关问题的声音开/关。当声音开启时，手机可以通过电子邮件接收语音信息。
This negotiation framework has not been designed with ephemeral capabilities in mind, but, with care, may be adaptable to deal with them.
这个谈判框架的设计并没有考虑到短暂的能力，但是，如果小心的话，可能适合处理这些能力。
Bearing in mind privacy concerns, implementers should be careful that systems do not automatically enter into a negotiation exchange in a way that may disclose the recipient's whereabouts without first having obtained explicit permission. For example, if receiving a message depends in any way on the user's physical presence, automatic negotiation should not be performed.
考虑到隐私问题，实施者应该小心，系统不会在未获得明确许可的情况下自动进入协商交换，从而可能会披露接收者的行踪。例如，如果接收消息以任何方式取决于用户的实际存在，则不应执行自动协商。
While it may be OK for an unattended fax machine to perform automated negotiation, it is not OK for a PC software package to do so without the users explicit permission as the PC may be switched on only when the user is present. This suggests that default settings in this regard should take account of the type of system.
虽然无人值守的传真机可以执行自动协商，但如果没有用户的明确许可，PC软件包不可以执行自动协商，因为PC只有在用户在场时才能打开。这表明，这方面的默认设置应考虑系统类型。
Appendix B: Candidates for further enhancements
附录B：进一步改进的候选方案
This appendix lists some possible features of content negotiation that were considered, but not included in the current specification. In most cases the reasons for exclusion were (a) that they could introduce unanticipated additional complexities, and (b) no compelling requirement was recognized.
本附录列出了已考虑但未包含在当前规范中的内容协商的一些可能特征。在大多数情况下，排除的原因是（a）它们可能会带来意想不到的额外复杂性，以及（b）没有认识到强制性要求。
o Cache control indicator for recipient capabilities. This would instruct the sender, or other message system component, that capability information in the current message is for the current transaction only, and should NOT be remembered for future transactions. E.g., a recipient may not wish colour capability to be used for routine communications. (See also section A.5 above.)
o 收件人功能的缓存控制指示器。这将指示发送方或其他消息系统组件，当前消息中的功能信息仅用于当前事务，不应在将来的事务中记住。例如，收件人可能不希望在日常通信中使用颜色功能。（另见上文第A.5节。）
o Use of q-values [6] in media feature expressions for indicating preference among alternatives available and/or receiver preferences.
o 在媒体特征表达式中使用q值[6]来指示可用备选方案和/或接收器偏好中的偏好。
o Partial re-sends. There are proposals being developed for "partial MDN" responses that can indicate disposition status on a per-message-part basis. This opens the possibility of partial re-sends when alternative formats are requested for only some of the message body parts. The current specification assumes that either none or all of message is re-sent when content negotiation is used.
o 部分重新发送。正在为“部分MDN”响应制定建议，这些响应可以根据每个消息部分指示处置状态。当仅为某些消息正文部分请求替代格式时，这就打开了部分重新发送的可能性。当前规范假定在使用内容协商时，不会重新发送任何消息或全部消息。
o Allow negotiation with parties other than originally addressed recipients of a message.
o 允许与邮件的原始收件人以外的其他方进行协商。
o Negotiation response might indicate different receiver endpoint with different capabilities.
o 协商响应可能指示具有不同功能的不同接收方端点。
Authors' Addresses
作者地址
Graham Klyne (editor) Clearswift Corporation, 1310 Waterside, Arlington Business Park Theale Reading, RG7 4SA United Kingdom
Graham Klyne（编辑）Clearwift公司，1310 Waterside，阿灵顿商业园Theale Reading，RG7 4SA英国
Phone: +44 11 8903 8903
Fax: +44 11 8903 9000
EMail: GK@ACM.ORG
Phone: +44 11 8903 8903
Fax: +44 11 8903 9000
EMail: GK@ACM.ORG
Ryuji Iwazaki TOSHIBA TEC CORPORATION 2-4-1, Shibakoen, Minato-ku, Tokyo, 105-8524 Japan
岩崎龙治东芝TEC公司2-4-1，日本东京弥敦区Shibakoen，邮编：105-8524
Phone: +81 3 3438 6866
Fax: +81 3 5402 6355
EMail: iwa@rdl.toshibatec.co.jp
Phone: +81 3 3438 6866
Fax: +81 3 5402 6355
EMail: iwa@rdl.toshibatec.co.jp
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 USA
Dave Crocker Brandenburg互联网675 Spruce Dr.Sunnyvale，加利福尼亚州，美国94086
Phone: +1 408 246 8253
Fax: +1 408 249 6205
EMail: dcrocker@brandenburg.com
Phone: +1 408 246 8253
Fax: +1 408 249 6205
EMail: dcrocker@brandenburg.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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编辑功能的资金目前由互联网协会提供。