Network Working Group D. Crocker
Request for Comments: 4142 Brandenburg
Category: Standards Track G. Klyne
Nine by Nine
November 2005
Network Working Group D. Crocker
Request for Comments: 4142 Brandenburg
Category: Standards Track G. Klyne
Nine by Nine
November 2005
Full-mode Fax Profile for Internet Mail (FFPIM)
Internet邮件的完整模式传真配置文件（FFPIM）
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
Classic facsimile document exchange represents both a set of technical specifications and a class of service. Previous work has replicated some of that service class as a profile within Internet mail. The current specification defines "full mode" carriage of facsimile data over the Internet, building upon that previous work and adding the remaining functionality necessary for achieving reliability and capability negotiation for Internet mail, on a par with classic T.30 facsimile. These additional features are designed to provide the highest level of interoperability with the standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates what is currently enjoyed by fax users.
经典的传真文件交换代表了一套技术规范和一类服务。以前的工作已经将该服务类中的一些复制为Internet mail中的配置文件。目前的规范定义了因特网上传真数据的“全模式”传输，建立在以前的工作基础之上，并添加了与因特网T.30传真相媲美的用于实现因特网邮件的可靠性和能力协商所需的剩余功能。这些附加功能旨在提供与符合标准的电子邮件基础架构和邮件用户代理的最高级别的互操作性，同时提供与传真用户当前享受的服务水平接近的服务水平。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Content Negotiation . . . . . . . . . . . . . . . . . . . . . . 3
2.1. UA-based Content Negotiation. . . . . . . . . . . . . . . . 3
2.2. ESMTP-based Content Negotiation . . . . . . . . . . . . . . 3
2.3. Interactions between UA and ESMTP Negotiation Mechanisms. . 4
3. Content Format . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References. . . . . . . . . . . . . . . . . . . . 5
5.2. Informative References. . . . . . . . . . . . . . . . . . . 6
A. Direct Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . 7
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Content Negotiation . . . . . . . . . . . . . . . . . . . . . . 3
2.1. UA-based Content Negotiation. . . . . . . . . . . . . . . . 3
2.2. ESMTP-based Content Negotiation . . . . . . . . . . . . . . 3
2.3. Interactions between UA and ESMTP Negotiation Mechanisms. . 4
3. Content Format . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References. . . . . . . . . . . . . . . . . . . . 5
5.2. Informative References. . . . . . . . . . . . . . . . . . . 6
A. Direct Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . 7
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
This specification defines "full mode" carriage of facsimile data over the Internet, building upon previous work in A Simple Mode of Facsimile Using Internet Mail [RFC3965] and Extended Facsimile Using Internet Mail [RFC2532]. This specification also adds the remaining functionality necessary to achieve reliable and capable negotiation for Internet mail, on par with classic [T30] facsimile. These additional features are designed to provide the highest level of interoperability with the standards-compliant email infrastructure and mail user agents, while providing a level of service that closely approximates the level of service currently enjoyed by fax users.
本规范定义了互联网上传真数据的“全模式”传输，建立在使用互联网邮件[RFC3965]的简单传真模式和使用互联网邮件[RFC2532]的扩展传真模式的基础上。该规范还添加了必要的剩余功能，以实现与互联网邮件的可靠和有能力的谈判，与经典[T30]传真相媲美。这些附加功能旨在提供与符合标准的电子邮件基础结构和邮件用户代理的最高级别的互操作性，同时提供与传真用户当前享受的服务级别非常接近的服务级别。
Basic terminology is discussed in [RFC2542]. Implementations that conform to this specification MUST also conform to [RFC3965] and [RFC2532].
[RFC2542]中讨论了基本术语。符合本规范的实施还必须符合[RFC3965]和[RFC2532]。
The new features are designed to be interoperable with the existing base of mail transfer agents (MTAs) and mail user agents (MUAs), and to take advantage of existing standards for optional functionality (e.g., positive delivery confirmation and disposition notification). Enhancements described in this document utilize the existing Internet email messaging infrastructure, where possible, instead of creating fax-specific features that are unlikely to be implemented in non-fax messaging software.
新功能旨在与现有的邮件传输代理（MTA）和邮件用户代理（MUA）进行互操作，并利用现有的可选功能标准（例如，正向传递确认和处置通知）。本文档中描述的增强功能尽可能利用现有的Internet电子邮件消息传递基础结构，而不是创建非传真消息传递软件中不可能实现的传真特定功能。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Classic facsimile service is interactive, such that a sending station can discover the capabilities of the receiving station, prior to sending a facsimile of a document. This permits the sender to transmit the best quality of facsimile supported by both the sending station and the receiving station. Internet mail is store-and-forward, with potentially long latency, such that before-the-fact negotiation is problematic.
经典的传真服务是交互式的，因此发送站可以在发送文件传真之前发现接收站的功能。这允许发送方传输发送站和接收站都支持的最佳传真质量。Internet邮件是存储和转发的，具有潜在的长延迟，因此在事实发生之前协商是有问题的。
Use of a negotiation mechanism permits senders to transfer a richer document form than is permitted when using the safer-but-universal default form. Without this mechanism, the sender of a document cannot be certain that the receiving station will be able to support the form.
使用协商机制允许发件人传输比使用更安全但通用的默认表单更丰富的文档表单。如果没有这种机制，文档的发送者无法确定接收站是否能够支持表单。
The capabilities that can be negotiated by an FFPIM participant are specified in [RFC2534] and [RFC2879]. Implementations that are conformant to FFPIM MUST support content negotiation as described there.
[RFC2534]和[RFC2879]中规定了FFPIM参与者可以协商的能力。符合FFPIM的实现必须支持此处所述的内容协商。
One method for exchanging the capabilities information uses a post-hoc technique, which permits an originator to send the best version known to be supported by the recipient, and to also send a better suited version if the recipient requests it. This mechanism is specified in [RFC3297]. FFPIM implementations MUST support this mechanism.
一种用于交换能力信息的方法使用事后技术，该技术允许发起者发送接收方支持的已知最佳版本，并在接收方请求时发送更适合的版本。[RFC3297]中规定了该机制。FFPIM实现必须支持这种机制。
Another method uses an ESMTP option specified in [RFC4141]. It requires support for content negotiation along the entire path the email travels. Using this mechanism, receiving ESMTP servers are able to report capabilities of the addresses (mailboxes) they support, and sending email clients are able to signal both permission and constraints on conversions.
Another method uses an ESMTP option specified in [RFC4141]. It requires support for content negotiation along the entire path the email travels. Using this mechanism, receiving ESMTP servers are able to report capabilities of the addresses (mailboxes) they support, and sending email clients are able to signal both permission and constraints on conversions.translate error, please retry
FFPIM participants MAY support this mechanism.
FFPIM参与者可能支持这种机制。
NOTE: This specification provides for content conversion by unspecified intermediaries. Use of this mechanism carries significant risk. Although intermediaries always have the ability to perform damaging transformations, use of this specification could result in more exploitation of that potential and, therefore, more misbehavior. Use of intermediaries is discussed in [RFC3238].
注：本规范规定由未指定的中介机构进行内容转换。使用这一机制会带来重大风险。尽管中介体总是能够执行破坏性的转换，但使用该规范可能会导致更多地利用该潜力，从而导致更多的错误行为。[RFC3238]中讨论了中介机构的使用。
FFPIM participants must ensure that their use of the UA and ESMTP methods for content negotiation is compatible. For example, two mechanisms might consult two different repositories of capabilities information, and those repositories might contain different information. Presumably, this means that at least one of these repositories is inaccurate. Therefore, the larger problem is one of correctness, rather than synchronization.
FFPIM参与者必须确保其在内容协商中使用的UA和ESMTP方法是兼容的。例如，两种机制可能查阅两个不同的功能信息存储库，而这些存储库可能包含不同的信息。这可能意味着这些存储库中至少有一个不准确。因此，更大的问题是正确性，而不是同步。
This specification does not require a particular method of using the mechanisms together.
本规范不要求同时使用这些机构的特定方法。
FFPIM allows the transfer of enhanced TIFF data relative to [RFC3965] and [RFC2532]. The details for these enhancements are contained in [RFC3949]. Implementations that are conformant to FFPIM SHOULD support TIFF enhancements.
FFPIM允许传输与[RFC3965]和[RFC2532]相关的增强型TIFF数据。这些增强功能的详细信息包含在[RFC3949]中。符合FFPIM的实现应支持TIFF增强。
It should also be noted that the content negotiation mechanism permits a sender to know the full range of content types that are supported by the recipient. Therefore, requirements for support of TIFF represent a functional minimum for FFPIM.
还应注意的是，内容协商机制允许发送方了解接收方支持的全部内容类型。因此，支持TIFF的要求是FFPIM的最低功能要求。
As this document is an extension of [RFC3965] and [RFC2532], the Security Considerations sections of [RFC3965] and [RFC2532] apply to this document, including discussion of PGP and S/MIME use for authentication and privacy.
由于本文件是[RFC3965]和[RFC2532]的扩展，[RFC3965]和[RFC2532]的安全注意事项部分适用于本文件，包括对PGP和S/MIME用于身份验证和隐私的讨论。
It appears that the mechanisms added by this specification do not introduce new security considerations. However, the concerns raised in [RFC2532] are particularly salient for these new mechanisms.
该规范添加的机制似乎没有引入新的安全注意事项。然而，[RFC2532]中提出的问题对于这些新机制尤为突出。
Use of this specification should occur with particular attention to the following security concerns:
使用本规范时应特别注意以下安全问题：
* Negotiation can be used as a denial of service attack.
* 协商可用作拒绝服务攻击。
* Negotiation may lead to the use of an unsafe data format.
* 协商可能导致使用不安全的数据格式。
* Negotiation discloses information and therefore raises privacy concerns.
* 协商会泄露信息，因此会引起隐私问题。
Use of the ESMTP CONNEG option permits content transformation by an intermediary, along the mail transfer path. When the contents are encrypted, the intermediary cannot perform the conversion, because it is not expected to have access to the relevant secret keying material. When the contents are signed, but not encrypted, conversion will invalidate the signature. Therefore, permission to convert SHOULD NOT normally be used with signed or sealed messages.
使用ESMTP CONNEG选项可以通过中介沿邮件传输路径进行内容转换。当内容被加密时，中介无法执行转换，因为它不能访问相关的密钥材料。当内容已签名但未加密时，转换将使签名无效。因此，转换权限通常不应与签名或密封邮件一起使用。
[RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for Content Conversion", RFC 4141, November 2005.
[RFC4141]丰田章男，K.和D.克罗克，“用于内容转换的SMTP和MIME扩展”，RFC41412005年11月。
[RFC3949] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J. Rafferty, "File Format for Internet Fax", RFC 3949, February 2005.
[RFC3949]Buckley，R.，Venable，D.，McIntyre，L.，Parsons，G.，和J.Rafferty，“互联网传真的文件格式”，RFC 3949，2005年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2532] Masinter, L. and D. Wing, " Extended Facsimile Using Internet Mail", RFC 2532, March 1999.
[RFC2532]Masinter，L.和D.Wing，“使用互联网邮件的扩展传真”，RFC 25321999年3月。
[RFC2534] Masinter, L., Wing, D., Mutz, A., and K. Holtman, "Media Features for Display, Print, and Fax", RFC 2534, March 1999.
[RFC2534]Masinter，L.，Wing，D.，Mutz，A.，和K.Holtman，“用于显示、打印和传真的媒体功能”，RFC 25341999年3月。
[RFC2542] Masinter, L., "Terminology and Goals for Internet Fax", RFC 2542, March 1999.
[RFC2542]Masinter，L.，“互联网传真的术语和目标”，RFC2542，1999年3月。
[RFC2879] Klyne, G. and L. McIntyre, "Content Feature Schema for Internet Fax (V2)", RFC 2879, August 2000.
[RFC2879]Klyne，G.和L.McIntyre，“互联网传真的内容特征模式（V2）”，RFC 28792000年8月。
[RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content Negotiation for Messaging Services based on Email", RFC 3297, July 2002.
[RFC3297]Klyne，G.，Iwazaki，R.，和D.Crocker，“基于电子邮件的消息传递服务的内容协商”，RFC 3297，2002年7月。
[RFC3965] Toyoda, K., Ohno, H., Murai, J., and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 3965, December 2004.
[RFC3965]丰田章男，K.，大野，H.，Murai，J.，和D.Wing，“使用互联网邮件的简单传真模式”，RFC 39652004年12月。
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[RFC3238]Floyd，S.和L.Daigle，“开放可插拔边缘服务的IAB体系结构和政策考虑”，RFC 3238，2002年1月。
[T30] ITU-T (CCITT), "Procedures for Document Facsimile Transmission in the General Switched Telephone Network", Recommendation T.30, July 1996.
[T30]ITU-T（CCITT），“通用交换电话网络中文件传真传输的程序”，建议T.30，1996年7月。
Email is a store-and-forward service, typically with highly variable delay between the time a message leaves the sender's realm and the time it arrives in the receiver's realm. The number of relays between sender and receiver is also unknown and variable. By contrast, facsimile is generally considered to be direct and immediate.
电子邮件是一种存储转发服务，通常在消息离开发送方领域和到达接收方领域之间具有高度可变的延迟。发送方和接收方之间的继电器数量也是未知和可变的。相比之下，传真通常被认为是直接和直接的。
An email profile that fully emulates facsimile must solve several different problems. One is to ensure that the document representation semantics are faithful. Another is that the interaction between sender and receiver is similar to that of telephony-based facsimile. In particular, it must ensure the timeliness of the interaction. The specifications for FFPIM and its predecessors enable email to emulate the former, the information (semantics) activities of facsimile.
完全模拟传真的电子邮件配置文件必须解决几个不同的问题。一是确保文档表示语义的忠实性。另一个是发送方和接收方之间的交互类似于基于电话的传真。特别是，它必须确保互动的及时性。FFPIM及其前身的规范使电子邮件能够模拟前者，即传真的信息（语义）活动。
The ESMTP CONNEG option sets the stage for achieving the latter, with email-based facsimile transfer that has interactive negotiations, on a par with telephony-based facsimile. The key, additional requirement is to achieve timeliness. Ultimately, timeliness requires configuring sender and receiver email servers to interact directly. The sender's MTA must directly contact the receiver's MTA. With typical email service configurations, the content and interaction semantics of facsimile can be emulated quite well, but timeliness cannot be assured.
ESMTP CONNEG选项为实现后者提供了阶段，基于电子邮件的传真传输与基于电话的传真相比，具有交互式协商。关键的附加要求是实现及时性。最终，时效性要求配置发送者和接收者电子邮件服务器以直接交互。发件人的MTA必须直接联系收件人的MTA。通过典型的电子邮件服务配置，可以很好地模拟传真的内容和交互语义，但无法保证及时性。
To achieve direct sending, the originating MTA must not use sending-side intermediaries such as outbound enterprise MTAs. Instead, it must be configured to do transmissions directly to hosts specified in email addresses, based on queries to the public DNS. To achieve direct receiving, the target MTAs must have DNS A records, without MX records. That is, they also must be configured not to use intermediaries.
要实现直接发送，发起MTA不得使用发送端中介，如出站企业MTA。相反，必须根据对公共DNS的查询，将其配置为直接向电子邮件地址中指定的主机进行传输。要实现直接接收，目标MTA必须有DNS A记录，而没有MX记录。也就是说，它们还必须配置为不使用中介。
The sender may then use ESMTP Conneg to determine the capabilities of the receiver. Afterwards the sender will use the capabilities information to tailor the TIFF message content it sends.
然后，发送方可以使用ESMTP Conneg来确定接收方的能力。之后，发送方将使用功能信息定制其发送的TIFF消息内容。
The IETF Fax working group, in collaboration with the IETF and the ITU, has diligently participated in a multi-year effort to produce Internet-based emulation of classic facsimile via email profiles. The effort benefited from the group's willingness to provide an initial, minimal mechanism, and then develop the specification to include more facsimile features as implementation and operation experience was gained.
IETF传真工作组与IETF和ITU合作，努力参与了多年的工作，通过电子邮件配置文件制作基于互联网的经典传真模拟。这项工作得益于该集团愿意提供一个初步的、最低限度的机制，然后随着实施和运营经验的积累，制定规范以包括更多传真功能。
Authors' Addresses
作者地址
Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA
戴夫·克罗克·勃兰登堡互联网络美国加利福尼亚州桑尼维尔市云杉大道675号，邮编94086
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
Graham Klyne Nine by Nine UK
格雷厄姆·克莱恩九乘九英国
Phone: EMail: GK-IETF@ninebynine.org
电话：电邮：GK-IETF@ninebynine.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。