Independent Submission T. Harding, Ed.
Request for Comments: 5402 Axway
Category: Informational February 2010
ISSN: 2070-1721
Independent Submission T. Harding, Ed.
Request for Comments: 5402 Axway
Category: Informational February 2010
ISSN: 2070-1721
Compressed Data within an Internet Electronic Data Interchange (EDI) Message
互联网电子数据交换（EDI）报文中的压缩数据
Abstract
摘要
This document explains the rules and procedures for utilizing compression (RFC 3274) within an Internet EDI (Electronic Data Interchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823.
本文件解释了在互联网EDI（电子数据交换）“AS”报文中使用压缩（RFC 3274）的规则和程序，如RFC 3335、4130和4823中所定义。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5402.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5402.
IESG Note
IESG注释
The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work. This RFC is not a candidate for any level of Internet Standard. Readers of this RFC should exercise caution in evaluating its value for implementation and deployment.
IETF曾考虑过本RFC的内容，因此它可能类似于当前正在进行的IETF工作或已发布的IETF工作。本RFC不适用于任何级别的互联网标准。本RFC的读者应谨慎评估其实施和部署价值。
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents
本文件受BCP 78和IETF信托有关IETF文件的法律规定（http:truster.IETF.org/license info）的约束，这些法律规定在本文件出版之日生效。请审阅这些文件
carefully, as they describe your rights and restrictions with respect to this document.
请仔细阅读，因为他们描述了您对本文件的权利和限制。
Historically, electronic messages produced by systems following the guidelines as outlined in the IETF EDIINT Working Group specifications AS1 [AS1], AS2 [AS2], and AS3 [AS3] did not have a way to provide a standardized transport neutral mechanism for compressing large payloads. However, with the development of RFC 3274, "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", we now have a transport-neutral mechanism for compressing large payloads.
从历史上看，由遵循IETF EDIINT工作组规范AS1[AS1]、AS2[AS2]和AS3[AS3]中概述的指南的系统生成的电子消息无法提供压缩大型有效负载的标准化传输中性机制。然而，随着RFC3274“加密消息语法的压缩数据内容类型（CMS）”的开发，我们现在有了一种与传输无关的机制来压缩大型有效负载。
A typical EDIINT 'AS' message is a multi-layered MIME message, consisting of one or more of the following: payload layer, signature layer, and/or encryption layer. When an 'AS' message is received, a Message Integrity Check (MIC) value must be computed based upon defined rules within the EDIINT 'AS' RFCs and must be returned to the sender of the message via a Message Disposition Notification (MDN).
典型的EDIINT“AS”消息是一个多层MIME消息，由以下一个或多个组成：有效负载层、签名层和/或加密层。收到“AS”消息时，必须根据EDIINT“AS”RFC中定义的规则计算消息完整性检查（MIC）值，并且必须通过消息处置通知（MDN）返回给消息的发送者。
The addition of a new compression layer will require this document to outline new procedures for building/layering 'AS' messages and computing a MIC value that is returned in the MDN receipt.
添加新的压缩层需要本文档概述构建/分层“AS”消息和计算MDN回执中返回的MIC值的新过程。
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]中所述进行解释。
The compressed-data CMS (Cryptographic Message Syntax) MIME entity as described in [COMPRESSED-DATA] may encapsulate a MIME entity that consists of either an unsigned or signed business document.
[compressed-data]中描述的压缩数据CMS（加密消息语法）MIME实体可以封装由未签名或签名的业务文档组成的MIME实体。
Implementers are to follow the appropriate specifications identified in the "MIME Media Types" registry [MIME-TYPES] maintained by IANA for the type of object being packaged. For example, to package an XML object, the MIME media type of "application/xml" is used in the Content-Type MIME header field and the specifications for enveloping the object are contained in [XMLTYPES].
实现者应遵循IANA维护的“MIME媒体类型”注册表[MIME-Types]中针对打包对象类型确定的适当规范。例如，要打包XML对象，在内容类型MIME头字段中使用MIME媒体类型“application/XML”，封装对象的规范包含在[XMLTYPES]中。
MIME entity example:
MIME实体示例：
Content-type: application/xml; charset="utf-8"
Content-type: application/xml; charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?>
<!-- sample xml document -->
<?xml version="1.0" encoding="UTF-8"?>
<!-- sample xml document -->
The MIME entity will be compressed using [ZLIB] and placed inside a CMS compressed-data object as outlined in [COMPRESSED-DATA]. The compressed-data object will be MIME encapsulated according to details outlined in [S/MIME3.1], RFC 3851, Section 3.5.
MIME实体将使用[ZLIB]进行压缩，并放置在CMS压缩数据对象中，如[compressed-data]中所述。压缩数据对象将根据[S/MIME3.1]，RFC 3851，第3.5节中概述的细节进行MIME封装。
Example:
例子：
Content-Type: application/pkcs7-mime; smime-type=compressed-data;
name=smime.p7z
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7z
Content-Type: application/pkcs7-mime; smime-type=compressed-data;
name=smime.p7z
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7z
MIAGCyqGSIb3DQEJEAEJoIAwgAIBADANBgsqhkiG9w0BCRADCDCABgkqhkiG9w0BBwGg
Hnic7ZRdb9owFIbvK/k/5PqVYPFXGK12YYyboVFASSp1vQtZGiLRACZE49/XHoUW7S/0
fU5ivWnasml72XFb3gb5druui7ytN803M570nii7C5r8tfwR281hy/p/KSM3+jzH5s3+
P3VT3QbLusnt8WPIuN5vN/vaA2+DulnXTXkXvNTr8j8ouZmkCmGI/UW+ZS/C8zP0bz2d
UEk2M8mlaxjRMByAhZTj0RGYg4TvogiRASROsZgjpVcJCb1KV6QzQeDJ1XkoQ5Jm+C5P
v+ORAcshOGeCcdFJyfgFxdtCdEcmOrbinc/+BBMzRThEYpwl+jEBpciSGWQkI0TSlREm
SGLuESm/iKUFt1y4XHBO2a5oq0IKJKWLS9kUZTA7vC5LSxYmgVL46SIWxIfWBQd6Adrn
vGxVibLqRCtIpp4g2qpdtqK1LiOeolpVK5wVQ5P7+QjZAlrh0cePYTx/gNZuB9Vhndtg
W9ogK+3rnmg3YWygnTuF5GDS+Q/jIVLnCcYZFc6Kk/+c80wKwZjwdZIqDYWRH68MuBQS
3CAaYOBNJMliTl0X7eV5DnoKIFSKYdj3cRpD/cK/JWTHJRe76MUXnfBW8m7Hd5zhQ4ri
+kV1/3AGSlJ32bFPd2BsQD8uSzIx6lObkjdz95c0AAAAAAAAAAAAAAAA
MIAGCyqGSIb3DQEJEAEJoIAwgAIBADANBgsqhkiG9w0BCRADCDCABgkqhkiG9w0BBwGg
Hnic7ZRdb9owFIbvK/k/5PqVYPFXGK12YYyboVFASSp1vQtZGiLRACZE49/XHoUW7S/0
fU5ivWnasml72XFb3gb5druui7ytN803M570nii7C5r8tfwR281hy/p/KSM3+jzH5s3+
P3VT3QbLusnt8WPIuN5vN/vaA2+DulnXTXkXvNTr8j8ouZmkCmGI/UW+ZS/C8zP0bz2d
UEk2M8mlaxjRMByAhZTj0RGYg4TvogiRASROsZgjpVcJCb1KV6QzQeDJ1XkoQ5Jm+C5P
v+ORAcshOGeCcdFJyfgFxdtCdEcmOrbinc/+BBMzRThEYpwl+jEBpciSGWQkI0TSlREm
SGLuESm/iKUFt1y4XHBO2a5oq0IKJKWLS9kUZTA7vC5LSxYmgVL46SIWxIfWBQd6Adrn
vGxVibLqRCtIpp4g2qpdtqK1LiOeolpVK5wVQ5P7+QjZAlrh0cePYTx/gNZuB9Vhndtg
W9ogK+3rnmg3YWygnTuF5GDS+Q/jIVLnCcYZFc6Kk/+c80wKwZjwdZIqDYWRH68MuBQS
3CAaYOBNJMliTl0X7eV5DnoKIFSKYdj3cRpD/cK/JWTHJRe76MUXnfBW8m7Hd5zhQ4ri
+kV1/3AGSlJ32bFPd2BsQD8uSzIx6lObkjdz95c0AAAAAAAAAAAAAAAA
Note: Content-Transfer-Encoding of base64 would only be required if the compressed-data MIME bodypart is transferred via a 7-bit protocol like SMTP and is visible in the outer layer of the MIME message. If the compressed-data MIME bodypart is placed inside of an encrypted MIME bodypart, content-transfer-encoding would not be required on the compressed-data MIME bodypart, but would be required on the encrypted MIME bodypart.
注意：仅当压缩数据MIME bodypart通过7位协议（如SMTP）传输并且在MIME消息的外层可见时，才需要base64的内容传输编码。如果压缩数据MIME bodypart放在加密的MIME bodypart中，则压缩数据MIME bodypart上不需要内容传输编码，但加密的MIME bodypart上需要内容传输编码。
When compressing a document that will be signed, the application MAY compress the innermost MIME body before signing (see Sections 3.2 and 3.5), or it MAY compress the outer multipart/signed MIME body (see Sections 3.3 and 3.6), but it MUST NOT do both within the same document. The receiving application MUST support both methods of compression when unpackaging an inbound document.
压缩将要签名的文档时，应用程序可以在签名之前压缩最里面的MIME正文（请参见第3.2节和第3.5节），也可以压缩外部多部分/已签名的MIME正文（请参见第3.3节和第3.6节），但不能在同一文档中同时执行这两个操作。在解包入站文档时，接收应用程序必须支持两种压缩方法。
Note: The following sections (3.1 - 3.6) show the individual layers of a properly formatted EDI MIME message with a compressed data layer. Please refer to the appropriate RFCs for the proper construction of the resulting MIME message. "application/xxxxxxx" is used to indicate an application media subtype.
注：以下部分（3.1-3.6）显示了具有压缩数据层的正确格式的EDI MIME消息的各个层。请参阅相应的RFC，以了解生成的MIME消息的正确构造。“application/xxxxxxx”用于表示应用程序媒体子类型。
-RFC5322/2045
-[COMPRESSED-DATA](application/pkcs7-mime)
-[MIME-TYPES](application/xxxxxxx)(compressed)
-RFC5322/2045
-[COMPRESSED-DATA](application/pkcs7-mime)
-[MIME-TYPES](application/xxxxxxx)(compressed)
This section shows the layers of an unsigned, unencrypted compressed message. The first line indicates that the MIME message conforms to [RFC5322] and [RFC2045] with a Content-Type of application/pkcs7-mime. Within the pkcs7-mime entity is a compressed MIME entity containing the electronic business document.
本节显示未签名、未加密的压缩消息的层。第一行表示MIME消息符合[RFC5322]和[RFC2045]，内容类型为application/pkcs7 MIME。pkcs7中的mime实体是包含电子商务文档的压缩mime实体。
-RFC5322/2045
-[RFC1847] (multipart/signed)
-[COMPRESSED-DATA](application/pkcs7-mime)
-[MIME-TYPES](application/xxxxxxx)(compressed)
-RFC3851 (application/pkcs7-signature)
-RFC5322/2045
-[RFC1847] (multipart/signed)
-[COMPRESSED-DATA](application/pkcs7-mime)
-[MIME-TYPES](application/xxxxxxx)(compressed)
-RFC3851 (application/pkcs7-signature)
This section shows the layers of a signed, unencrypted compressed message where the payload is compressed before being signed.
本节显示已签名、未加密的压缩消息的各层，其中有效负载在签名之前被压缩。
-RFC5322/2045
-[COMPRESSED-DATA](application/pkcs7-mime)
-[RFC1847] (multipart/signed)(compressed)
-[MIME-TYPES](application/xxxxxxx)(compressed)
-RFC3851 (application/pkcs7-signature)(compressed)
-RFC5322/2045
-[COMPRESSED-DATA](application/pkcs7-mime)
-[RFC1847] (multipart/signed)(compressed)
-[MIME-TYPES](application/xxxxxxx)(compressed)
-RFC3851 (application/pkcs7-signature)(compressed)
This section shows the layers of a signed, unencrypted compressed message where a signed payload is compressed.
本节显示已签名、未加密的压缩消息的层，其中已签名的有效负载被压缩。
-RFC5322/2045
-RFC3851 (application/pkcs7-mime)
-[COMPRESSED-DATA](application/pkcs7-mime) (encrypted)
-[MIME-TYPES](application/xxxxxxx)(compressed)(encrypted)
-RFC5322/2045
-RFC3851 (application/pkcs7-mime)
-[COMPRESSED-DATA](application/pkcs7-mime) (encrypted)
-[MIME-TYPES](application/xxxxxxx)(compressed)(encrypted)
This section shows the layers of an unsigned, encrypted compressed message where the payload is compressed before it is encrypted.
本节显示未签名、加密的压缩消息的层，其中有效负载在加密之前被压缩。
-RFC5322/2045
-RFC3851 (application/pkcs7-mime)
-[RFC1847] (multipart/signed) (encrypted)
-[COMPRESSED-DATA](application/pkcs7-mime) (encrypted)
-[MIME-TYPES](application/xxxxxxx) (compressed)(encrypted)
-RFC3851 (application/pkcs7-signature) (encrypted)
-RFC5322/2045
-RFC3851 (application/pkcs7-mime)
-[RFC1847] (multipart/signed) (encrypted)
-[COMPRESSED-DATA](application/pkcs7-mime) (encrypted)
-[MIME-TYPES](application/xxxxxxx) (compressed)(encrypted)
-RFC3851 (application/pkcs7-signature) (encrypted)
This section shows the layers of a signed, encrypted compressed message where the payload is compressed before being signed and encrypted.
本节显示已签名、加密的压缩消息的层，其中有效负载在签名和加密之前被压缩。
-RFC5322/2045
-RFC3851 (application/pkcs7-mime)
-[COMPRESSED-DATA](application/pkcs7-mime) (encrypted)
-[RFC1847] (multipart/signed) (compressed)(encrypted)
-[MIME-TYPES](application/xxxxxxx) (compressed)(encrypted)
-RFC3851 (application/pkcs7-signature)(compressed)(encrypted)
-RFC5322/2045
-RFC3851 (application/pkcs7-mime)
-[COMPRESSED-DATA](application/pkcs7-mime) (encrypted)
-[RFC1847] (multipart/signed) (compressed)(encrypted)
-[MIME-TYPES](application/xxxxxxx) (compressed)(encrypted)
-RFC3851 (application/pkcs7-signature)(compressed)(encrypted)
This section shows the layers of a signed, encrypted compressed message where the payload is signed before being compressed and encrypted.
本节显示已签名、加密的压缩消息的层，其中有效负载在压缩和加密之前已签名。
For any signed message, the MIC to be returned is calculated over the same data that was signed in the original message as per [AS1]. The signed content will be a MIME bodypart that contains either compressed or uncompressed data.
对于任何已签名的消息，根据[AS1]根据原始消息中已签名的相同数据计算要返回的MIC。签名内容将是包含压缩或未压缩数据的MIME bodypart。
For encrypted, unsigned messages, the MIC to be returned is calculated over the uncompressed data content including all MIME header fields and any applied Content-Transfer-Encoding.
对于加密的、未签名的消息，将在未压缩的数据内容（包括所有MIME头字段和任何应用的内容传输编码）上计算要返回的MIC。
For unsigned, unencrypted messages, the MIC is calculated over the uncompressed data content including all MIME header fields and any applied Content-Transfer-Encoding.
对于未签名、未加密的消息，将根据未压缩的数据内容（包括所有MIME头字段和任何应用的内容传输编码）计算MIC。
For a received message where a receipt has been requested and decompression fails, the following disposition modifier will be returned in the signed MDN.
对于已请求接收但解压缩失败的已接收消息，将在已签名MDN中返回以下处置修饰符。
"Error: decompression-failed" - the receiver could not decompress the message
“错误：解压缩失败”-接收器无法解压缩消息
Any application that supports the compression methods outlined within this document MUST use a version identifier value of "1.1" or greater within the AS2 or AS3 Version header field as describe in [AS2] and [AS3].
任何支持本文档中概述的压缩方法的应用程序必须在AS2或AS3版本标题字段中使用版本标识符值“1.1”或更大，如[AS2]和[AS3]中所述。
Implementations MUST support ZLIB [ZLIB], which utilizes DEFLATE [DEFLATE].
实现必须支持ZLIB[ZLIB]，它利用DEFLATE[DEFLATE]。
This document is not concerned with security, except for any security concerns mentioned in the referenced RFCs.
本文件不涉及安全问题，参考RFC中提及的任何安全问题除外。
[AS1] Harding, T., Drummond, R., and C. Shih, "MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet", RFC 3335, September 2002.
[AS1]Harding，T.，Drummond，R.，和C.Shih，“互联网上基于MIME的安全对等业务数据交换”，RFC 3335，2002年9月。
[AS2] Moberg, D. and R. Drummond, "MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)", RFC 4130, July 2005.
[AS2]Moberg，D.和R.Drummond，“使用HTTP的基于MIME的安全对等业务数据交换，适用性声明2（AS2）”，RFC 4130，2005年7月。
[AS3] Harding, T. and R. Scott, "FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet", RFC 4823, April 2007.
[AS3]Harding，T.和R.Scott，“互联网上安全对等业务数据交换的FTP传输”，RFC 4823，2007年4月。
[ZLIB] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[ZLIB]Deutsch，P.和J-L.Gailly，“ZLIB压缩数据格式规范3.3版”，RFC 1950，1996年5月。
[DEFLATE] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[DEFLATE]Deutsch，P.，“DEFLATE压缩数据格式规范1.3版”，RFC1951，1996年5月。
[MIME-TYPES] IANA, "MIME Media Types" registry, available from http://www.iana.org.
[MIME-TYPES]IANA，“MIME媒体类型”注册表，可从http://www.iana.org.
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[RFC1847]Galvin，J.，Murphy，S.，Crocker，S.，和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[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月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[S/MIME3.1] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[S/MIME3.1]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 5751，2010年1月。
[XMLTYPES] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[XMLTYPES]Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[COMPRESSED-DATA] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[COMPRESSED-DATA]Gutmann，P.，“加密消息语法（CMS）的压缩数据内容类型”，RFC 3274，2002年6月。
A number of the members of the EDIINT Working Group have also worked very hard and contributed to this document. The following people have made direct contributions to this document:
EDIINT工作组的一些成员也非常努力地工作，并为本文件作出了贡献。以下人员对本文件作出了直接贡献：
David Fischer, Dale Moberg, Robert Asis, and everyone involved in the AS1, AS2 Interop testing during 2002.
David Fischer、Dale Moberg、Robert Asis以及2002年参与AS1、AS2互操作测试的所有人。
Author's Address
作者地址
Terry Harding Axway Scottsdale, Arizona USA
Terry Harding Axway Scottsdale，美国亚利桑那州
EMail: tharding@us.axway.com
EMail: tharding@us.axway.com