Network Working Group T. Harding
Request for Comments: 4823 R. Scott
Category: Informational Axway
April 2007
Network Working Group T. Harding
Request for Comments: 4823 R. Scott
Category: Informational Axway
April 2007
FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet
FTP传输，用于在Internet上进行安全的对等业务数据交换
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message.
本适用性声明（AS）描述了如何使用XML、二进制、电子数据交换（EDI-ANSI X12或UN/EDIFACT）的文件传输协议（FTP）安全地交换结构化业务数据，或用于企业对企业数据交换的其他数据，可以使用标准MIME内容类型完成MIME打包。身份验证和数据机密性是通过使用加密消息语法（S/MIME）安全主体部分获得的。经过身份验证的确认使用对原始消息的多部分/签名回复。
Table of Contents
目录
1. Introduction ....................................................4
2. Overview ........................................................4
2.1. Overall Operations .........................................4
2.2. Purpose of a Security Guideline for MIME EDI ...............5
2.3. Definitions ................................................5
2.3.1. Terms ...............................................5
2.3.2. The Secure Transmission Loop ........................6
2.3.3. Definition of Receipts ..............................7
2.4. Operational Assumptions and Options ........................8
2.4.1. EDI/EC Process Assumptions ..........................8
2.4.2. Process Options .....................................8
2.4.2.1. Security Options ...........................8
2.4.2.2. Compression Options .......................10
3. Referenced RFCs and Their Contribution .........................10
3.1. RFC 959: File Transfer Protocol [3] .......................10
3.2. RFC 2228: FTP Security Extensions [4] .....................10
3.3. RFC 1847: MIME Security Multiparts [7] ....................10
3.4. RFC 3462: Multipart/Report [12] ...........................11
3.5. RFC 1767: EDI Content [2] .................................11
3.6. RFCs 2045, 2046, and 2049: MIME [1] .......................11
3.7. RFC 3798: Message Disposition Notification [6] ............11
3.8. RFC 3852: CMS [9] and RFC 3851: S/MIME Version 3.1
Message Specification [10] ................................11
3.9. RFC 3850: S/MIME Version 3.1 Certificate Handling [11] ....11
3.10. RFC 3274: Compressed Data Content Type for
Cryptographic Message Syntax (CMS) [17] ..................11
3.11. RFC 3023: XML Media Types [16] ...........................12
4. Structure of an AS3 Message ....................................12
4.1. Introduction ..............................................12
4.2. Structure of an Internet EDI MIME Message .................12
5. AS3-Specific Headers ...........................................13
5.1. AS3-From and AS3-To Headers ...............................13
5.2. AS3-Version Header ........................................14
6. FTP Considerations .............................................15
6.1. FTP Security Requirements .................................15
6.2. Large File Transfers ......................................15
6.3. MIME Considerations for FTP ...............................15
6.3.1. Required/Optional Headers ..........................15
6.3.2. Content-Transfer-Encoding ..........................16
6.3.3. Epilogue Must Be Empty .............................16
6.3.4. Message-Id and Original-Message-Id .................16
7. Structure and Processing of an MDN Message .....................17
7.1. Introduction ..............................................17
7.2. Message Disposition Notifications (MDN) ...................19
7.3. Requesting a Signed Receipt ...............................19
7.3.1. Signed Receipt Considerations ......................22
1. Introduction ....................................................4
2. Overview ........................................................4
2.1. Overall Operations .........................................4
2.2. Purpose of a Security Guideline for MIME EDI ...............5
2.3. Definitions ................................................5
2.3.1. Terms ...............................................5
2.3.2. The Secure Transmission Loop ........................6
2.3.3. Definition of Receipts ..............................7
2.4. Operational Assumptions and Options ........................8
2.4.1. EDI/EC Process Assumptions ..........................8
2.4.2. Process Options .....................................8
2.4.2.1. Security Options ...........................8
2.4.2.2. Compression Options .......................10
3. Referenced RFCs and Their Contribution .........................10
3.1. RFC 959: File Transfer Protocol [3] .......................10
3.2. RFC 2228: FTP Security Extensions [4] .....................10
3.3. RFC 1847: MIME Security Multiparts [7] ....................10
3.4. RFC 3462: Multipart/Report [12] ...........................11
3.5. RFC 1767: EDI Content [2] .................................11
3.6. RFCs 2045, 2046, and 2049: MIME [1] .......................11
3.7. RFC 3798: Message Disposition Notification [6] ............11
3.8. RFC 3852: CMS [9] and RFC 3851: S/MIME Version 3.1
Message Specification [10] ................................11
3.9. RFC 3850: S/MIME Version 3.1 Certificate Handling [11] ....11
3.10. RFC 3274: Compressed Data Content Type for
Cryptographic Message Syntax (CMS) [17] ..................11
3.11. RFC 3023: XML Media Types [16] ...........................12
4. Structure of an AS3 Message ....................................12
4.1. Introduction ..............................................12
4.2. Structure of an Internet EDI MIME Message .................12
5. AS3-Specific Headers ...........................................13
5.1. AS3-From and AS3-To Headers ...............................13
5.2. AS3-Version Header ........................................14
6. FTP Considerations .............................................15
6.1. FTP Security Requirements .................................15
6.2. Large File Transfers ......................................15
6.3. MIME Considerations for FTP ...............................15
6.3.1. Required/Optional Headers ..........................15
6.3.2. Content-Transfer-Encoding ..........................16
6.3.3. Epilogue Must Be Empty .............................16
6.3.4. Message-Id and Original-Message-Id .................16
7. Structure and Processing of an MDN Message .....................17
7.1. Introduction ..............................................17
7.2. Message Disposition Notifications (MDN) ...................19
7.3. Requesting a Signed Receipt ...............................19
7.3.1. Signed Receipt Considerations ......................22
7.4. MDN Format and Value ......................................23
7.4.1. AS3-MDN General Formats ............................23
7.4.2. AS3-MDN Construction ...............................24
7.4.3. AS3-MDN Fields .....................................25
7.4.4. Additional AS3-MDN Programming Notes ...............26
7.5. Disposition Mode, Type, and Modifier ......................29
7.5.1. Disposition Mode Overview ..........................29
7.5.2. Successful Processing Status Indication ............29
7.5.3. Unsuccessful Processed Content .....................29
7.5.4. Unsuccessful Non-Content Processing ................30
7.5.5. Processing Warnings ................................31
8. Public Key Certificate Handling ................................32
9. Security Considerations ........................................33
10. References ....................................................34
10.1. Normative References .....................................34
10.2. Informative References ...................................36
Appendix A. Message Examples ......................................37
A.1. Signed Message Requesting a Signed Receipt ................37
A.2. MDN for Message A.1 Above .................................37
7.4. MDN Format and Value ......................................23
7.4.1. AS3-MDN General Formats ............................23
7.4.2. AS3-MDN Construction ...............................24
7.4.3. AS3-MDN Fields .....................................25
7.4.4. Additional AS3-MDN Programming Notes ...............26
7.5. Disposition Mode, Type, and Modifier ......................29
7.5.1. Disposition Mode Overview ..........................29
7.5.2. Successful Processing Status Indication ............29
7.5.3. Unsuccessful Processed Content .....................29
7.5.4. Unsuccessful Non-Content Processing ................30
7.5.5. Processing Warnings ................................31
8. Public Key Certificate Handling ................................32
9. Security Considerations ........................................33
10. References ....................................................34
10.1. Normative References .....................................34
10.2. Informative References ...................................36
Appendix A. Message Examples ......................................37
A.1. Signed Message Requesting a Signed Receipt ................37
A.2. MDN for Message A.1 Above .................................37
Previous work on Internet EDI focused on specifying MIME content types for EDI data [2] and extending this work to support secure EC/EDI transport over SMTP [5]. This document expands on RFC 1767 to specify a comprehensive set of data security features, specifically, data privacy, data integrity, authenticity, non-repudiation of origin, and non-repudiation of receipt over FTP. This document also recognizes contemporary RFCs and is attempting to "re-invent" as little as possible. While this document focuses on EDI data, any other data type describable in a MIME format is also supported.
以前关于Internet EDI的工作重点是为EDI数据指定MIME内容类型[2]，并扩展此工作以支持SMTP上的安全EC/EDI传输[5]。本文档在RFC 1767的基础上进行了扩展，详细说明了一整套数据安全功能，特别是数据隐私、数据完整性、真实性、来源的不可否认性以及通过FTP接收的不可否认性。本文件也承认当代RFC，并试图尽可能少地“重新发明”。虽然本文档主要关注EDI数据，但也支持以MIME格式描述的任何其他数据类型。
Internet MIME-based EDI can be accomplished by using and complying with the following documents:
基于Internet MIME的EDI可以通过使用并遵守以下文档来实现：
- RFC 959: File Transfer Protocol - RFC 2228: FTP Security Extensions - RFC 1767: EDI Content Type - RFC 3023: XML Media Types - RFC 1847: Security Multiparts for MIME - RFC 3462: Multipart/Report - RFCs 2045 to 2049: MIME - RFC 3798: Message Disposition Notification - RFCs 3850, 3851, and 3852: S/MIME v3.1 Specifications - RFC 3274: Compressed Data Content for Cryptographic Message Syntax - RFC 4217: Securing FTP with TLS - "Compressed Data for EDIINT" by T. Harding
- RFC 959:文件传输协议-RFC 2228:FTP安全扩展-RFC 1767:EDI内容类型-RFC 3023:XML媒体类型-RFC 1847:MIME的安全多部分-RFC 3462:多部分/报告-RFCs 2045至2049:MIME-RFC 3798:消息处置通知-RFCs 38503851，和3852:S/MIME v3.1规范-RFC 3274：加密消息语法的压缩数据内容-RFC 4217：使用TLS保护FTP-T.Harding的“用于EDIINT的压缩数据”
Our intent here is to define clearly and precisely how these are used together, and what is required by user agents to be compliant with this document.
我们在这里的目的是明确和准确地定义如何将这些功能结合使用，以及用户代理需要什么才能符合本文档的要求。
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 [19].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[19]中所述进行解释。
An FTP upload operation is used to send appropriately packaged EDI, XML, or other business data. The receiving application will poll the FTP server for inbound messages, unpackage and handle the message data, and generate a reply for the originator that contains a message disposition acknowledgement within a multipart/report that is signed or unsigned. This request/reply transactional interchange provides secure, reliable, and authenticated transport for EDI or other
FTP上载操作用于发送适当打包的EDI、XML或其他业务数据。接收应用程序将轮询FTP服务器以获取入站消息，解包并处理消息数据，并为发起者生成一个回复，其中包含已签名或未签名的多部分/报告中的消息处置确认。此请求/应答事务交换为EDI或其他应用程序提供安全、可靠和经过身份验证的传输
business data using FTP. The security protocols and structures used also support auditable records of these transmissions.
使用FTP的业务数据。使用的安全协议和结构还支持这些传输的可审核记录。
The purpose of these specifications is to ensure interoperability between B2B Electronic Commerce user agents, invoking some or all of the commonly expected security features. This document is also NOT limited to strict EDI use, but applies to any electronic commerce application where business data needs to be exchanged over the Internet in a secure manner.
这些规范的目的是确保B2B电子商务用户代理之间的互操作性，调用一些或所有常见的预期安全特性。本文件也不限于严格的EDI使用，但适用于任何需要在互联网上以安全方式交换业务数据的电子商务应用程序。
AS3 Applicability Statement 3. This is the third applicability statement produced by the IETF EDIINT working group.
AS3适用性声明3。这是IETF EDIINT工作组编制的第三份适用性声明。
EDI Electronic Data Interchange
电子数据交换
EC Business-to-Business Electronic Commerce
电子商务
B2B Business to Business
B2B企业对企业
Receipt The functional message that is sent from a receiver to a sender to acknowledge receipt of an EDI/EC interchange.
接收从接收方发送给发送方的功能报文，以确认收到EDI/EC交换。
Signed Receipt A receipt containing a digital signature.
签名收据包含数字签名的收据。
Message Disposition The Internet messaging format used to convey a Notification (MDN) receipt. This term is used interchangeably with receipt. An MDN is a receipt.
消息处理用于传递通知（MDN）回执的Internet消息格式。该术语可与收据互换使用。MDN是一种收据。
Non-repudiation of NRR is a "legal event" that occurs when the receipt (NRR) original sender of an EDI/EC interchange has verified the signed receipt coming back from the receiver. NRR IS NOT a functional or a technical message.
NRR的不可抵赖性是一种“法律事件”，发生在EDI/EC交换的原始发送方的收据（NRR）已验证从接收方返回的签名收据时。NRR不是功能信息或技术信息。
S/MIME A format and protocol for adding Cryptographic signature and/or encryption services to Internet MIME messages.
S/MIME向Internet MIME消息添加加密签名和/或加密服务的格式和协议。
NOTE: While the S/MIME specification describes more than one format for a signed message, all signed messages or receipts used with AS3 MUST utilize the multipart/signed format.
注意：虽然S/MIME规范描述了签名消息的多种格式，但与AS3一起使用的所有签名消息或收据都必须使用多部分/签名格式。
SHA-1 A secure, one-way hash algorithm used in conjunction with digital signature. SHA-1 is the recommend algorithm for AS3.
SHA-1一种安全的单向散列算法，与数字签名结合使用。SHA-1是AS3的推荐算法。
MD5 A secure, one-way hash algorithm used in conjunction with digital signature. This algorithm is acceptable but not recommended due to its short key length and known weaknesses.
MD5一种安全的单向散列算法，与数字签名结合使用。该算法是可以接受的，但由于其密钥长度短和已知的弱点，不推荐使用。
MIC The message integrity check (MIC) is a representation of the message digest, which results from the application of the selected hash algorithm to the content to be signed. Of particular interest is the digital signature, which includes an encrypted copy of the digest. Additionally, an MDN containing a Received-content-MIC header will also contain (as that header's value) a base-64-encoded representation of the digest.
MIC消息完整性检查（MIC）是消息摘要的一种表示，它是对要签名的内容应用所选哈希算法的结果。特别令人感兴趣的是数字签名，其中包括摘要的加密副本。此外，包含接收内容MIC头的MDN还将包含（作为该头的值）摘要的base-64编码表示。
User Agent (UA) The application that handles and processes the AS3 request.
用户代理（UA）处理AS3请求的应用程序。
STL Secure Transmission Loop, described in the next section.
STL安全传输环路，将在下一节中介绍。
This document's focus is on the formats and protocols for exchanging EDI/EC content to which security services have been applied using the File Transmission Protocol (FTP) as the transport.
本文档的重点是交换EDI/EC内容的格式和协议，安全服务已使用文件传输协议（FTP）作为传输协议。
The "Secure Transmission Loop" (STL) comprises the following two steps:
“安全传输环路”（STL）包括以下两个步骤：
a) The originator sends a signed and encrypted document with a request for a signed receipt.
a) 发起人发送一份经过签名和加密的文档，并请求签署收据。
b) The recipient decrypts the document, verifies the signature, and returns a signed receipt to the sender.
b) 收件人解密文档，验证签名，并将签名收据返回给发件人。
In other words, the following events occur during the execution of the STL:
换句话说，在STL的执行过程中会发生以下事件：
- The organization sending EDI/EC data signs and encrypts the data using S/MIME. In addition, the message will request a signed receipt to be returned to the sender of the message.
- 发送EDI/EC数据的组织使用S/MIME对数据进行签名和加密。此外，该邮件将请求将已签名的回执返回给该邮件的发件人。
- The receiving organization decrypts the message and verifies the signature, resulting in verified integrity of the data and authenticity of the sender.
- 接收组织解密消息并验证签名，从而验证数据的完整性和发送方的真实性。
- The receiving organization then returns a signed receipt, as requested to the sending organization in the form of a message disposition notification. This signed receipt will contain the hash of the signature from the received message, indicating to the sender that the received message was verified and/or decrypted properly.
- 然后，接收组织按照发送组织的请求，以消息处置通知的形式将已签名的回执返回给发送组织。此签名回执将包含来自接收到的消息的签名散列，向发送方表明已正确验证和/或解密接收到的消息。
The above describes functionality that, if implemented, will satisfy all security requirements and provide non-repudiation of receipt for the exchange. While trading partners will usually want to utilize the STL, this specification does not require it.
上述描述的功能，如果实施，将满足所有安全要求，并为交易所提供收据的不可否认性。虽然贸易伙伴通常希望使用STL，但本规范并不要求使用STL。
The term used for both the functional activity and the message for acknowledging delivery of an EDI/EC interchange is "receipt" or "signed receipt". The term receipt is used if the acknowledgment is for an interchange resulting in a receipt that is NOT signed. The term signed receipt is used if the acknowledgment is for an interchange resulting in a receipt that IS signed. A term often used in combination with receipts is non-repudiation of receipt. NRR refers to a legal event that occurs only when the original sender of an interchange has verified the signed receipt coming back from the recipient of the message. Note that NRR is not possible without signatures.
用于确认EDI/EC交换交付的功能活动和信息的术语为“收据”或“签名收据”。如果确认是用于交换的，则使用术语“收据”，从而导致未签名的收据。如果确认是用于交换的，则使用术语“已签名收据”，从而生成已签名的收据。一个经常与收据结合使用的术语是收据的不可抵赖性。NRR是指仅当交换的原始发送方验证了从消息接收方返回的签名回执时才发生的法律事件。请注意，如果没有签名，NRR是不可能的。
For additional information on formatting and processing receipts in AS3, refer to Section 7.
有关AS3中收据格式和处理的更多信息，请参阅第7节。
- Encrypted object is an EDI/EC Interchange.
- 加密对象是EDI/EC交换。
This specification assumes that a typical EDI/EC interchange is the lowest level object that will be subject to the application of security services.
本规范假设典型的EDI/EC交换是受安全服务应用程序约束的最低级别对象。
Specifically, for EDI ANSI X12, the entire document (including the ISA and IEA segments) is the atom to which security is applied. For EDIFACT, the corresponding definition includes the segments UNA/UNB and UNZ. In other words, EDI/EC interchanges including envelope segments remain intact and unreadable during secure transport.
具体来说，对于EDI ANSI X12，整个文档（包括ISA和IEA段）就是应用安全性的原子。对于EDIFACT，相应的定义包括UNA/UNB和UNZ段。换言之，包括信封段在内的EDI/EC交换在安全运输期间保持完好无损且无法读取。
- EDI envelope headers are encrypted.
- EDI信封头是加密的。
Congruent with the above statement, EDI envelope headers are NOT visible in the MIME package. In order to optimize routing from existing commercial EDI networks (called Value Added Networks or VANs) to the Internet, work may need to be done in the future to define ways to extract some elements of the envelope to make them visible; however, that is beyond the scope of this specification.
与上述语句一致，EDI信封头在MIME包中不可见。为了优化从现有商业EDI网络（称为增值网络或VAN）到互联网的路由，未来可能需要确定提取信封某些元素以使其可见的方法；但是，这超出了本规范的范围。
- X12.58 and UN/EDIFACT security considerations
- X12.58和UN/EDIFACT安全注意事项
The most common EDI standards bodies, ANSI X12 and EDIFACT, have defined internal provisions for security. X12.58 is the security mechanism for ANSI X12, and AUTACK provides security for EDIFACT. This specification DOES NOT dictate use or non-use of these security standards. They are both fully compatible, though possibly redundant, with this specification.
最常见的EDI标准机构ANSI X12和EDIFACT定义了内部安全规定。X12.58是ANSI X12的安全机制，AUTACK为EDIFACT提供安全性。本规范不规定使用或不使用这些安全标准。它们都与本规范完全兼容，尽管可能是冗余的。
- Encrypted or un-encrypted data
- 加密或未加密的数据
This specification allows for EDI/EC message exchange where the EDI/EC data can be either un-protected or protected by means of encryption.
本规范允许EDI/EC消息交换，其中EDI/EC数据可以不受保护，也可以通过加密方式进行保护。
- Signed or unsigned data
- 有符号或无符号数据
This specification allows for EDI/EC message exchange with or without digital signature of the original EDI transmission.
本规范允许使用或不使用原始EDI传输的数字签名进行EDI/EC消息交换。
- Use of receipt or not
- 收据的使用与否
This specification allows for EDI/EC message transmission with or without a request for receipt notification. If a signed receipt notification is requested, however, a MIC value is REQUIRED as part of the returned receipt, unless an error condition occurs that results in the inability to compute a valid digest. (Such a case would result, for instance, if an encrypted message could not be decrypted.) Under such circumstances, an unsigned receipt (MDN) SHOULD be returned with the correct "disposition modifier" error value.
本规范允许EDI/EC消息传输，无论是否要求接收通知。但是，如果请求签名收据通知，则需要MIC值作为返回收据的一部分，除非出现导致无法计算有效摘要的错误情况。（例如，如果加密消息无法解密，则会出现这种情况。）在这种情况下，应返回未签名回执（MDN）并带有正确的“disposition modifier”错误值。
- Security formatting
- 安全格式
This specification relies on the guidelines set forth in RFCs 3852 [9] and 3851 [10]. The first of these RFCs describes the Cryptographic Message Syntax (CMS), and the second contains the S/MIME Version 3.1 Message Specification describing a MIME container for CMS objects. Whenever the term S/MIME is used in this document, it refers to Version 3.1 as described therein.
本规范依据RFCs 3852[9]和3851[10]中规定的指南。第一个RFC描述加密消息语法（CMS），第二个RFC包含S/MIME版本3.1消息规范，描述CMS对象的MIME容器。当本文件中使用术语S/MIME时，它指的是其中所述的版本3.1。
- Hash function, message digest choices
- 哈希函数，消息摘要选项
When a signature is used, it is RECOMMENDED that the SHA-1 hash algorithm be used for all outgoing messages; however, both MD5 and SHA-1 MUST be supported for incoming messages.
使用签名时，建议对所有传出消息使用SHA-1哈希算法；但是，传入消息必须同时支持MD5和SHA-1。
- Permutation summary
- 排列摘要
In summary, the following twelve security permutations are possible in any given trading relationship:
总之，在任何给定的交易关系中，以下十二种证券排列是可能的：
1. Sender sends un-encrypted data, does NOT request a receipt.
1. 发件人发送未加密的数据，不请求收据。
2. Sender sends un-encrypted data, requests an unsigned receipt. The receiver sends back the unsigned receipt.
2. 发送方发送未加密的数据，请求未签名的收据。接收方发回未签名的收据。
3. Sender sends un-encrypted data, requests a signed receipt. The receiver sends back the signed receipt.
3. 发送方发送未加密的数据，请求签署的收据。接收方发回已签名的收据。
4. Sender sends encrypted data, does NOT request a receipt.
4. 发送方发送加密数据，不请求收据。
5. Sender sends encrypted data, requests an unsigned receipt. The receiver sends back the unsigned receipt.
5. 发送方发送加密数据，请求未签名的收据。接收方发回未签名的收据。
6. Sender sends encrypted data, requests a signed receipt. The receiver sends back the signed receipt.
6. 发送方发送加密数据，请求签署收据。接收方发回已签名的收据。
7. Sender sends signed data, does NOT request a receipt.
7. 发送方发送签名数据，不请求收据。
8. Sender sends signed data, requests an unsigned receipt. Receiver sends back the unsigned receipt.
8. 发送方发送已签名的数据，请求未签名的收据。接收方发回未签字的收据。
9. Sender sends signed data, requests a signed receipt. Receiver sends back the signed receipt.
9. 发送方发送签名数据，请求签名收据。接收方发回已签名的收据。
10. Sender sends encrypted and signed data, does NOT request a receipt.
10. 发送方发送加密和签名的数据，不请求收据。
11. Sender sends encrypted and signed data, requests an unsigned receipt. Receiver sends back the unsigned receipt.
11. 发送方发送加密和签名的数据，请求未签名的收据。接收方发回未签字的收据。
12. Sender sends encrypted and signed data, requests a signed receipt. Receiver sends back the signed receipt. This case represents the Secure Transmission Loop described above.
12. 发送方发送加密和签名数据，请求签名收据。接收方发回已签名的收据。这种情况表示上述安全传输环路。
The AS3 specification supports compression of transmitted data directly through the application of RFC 3274. Implementation details may be found in that RFC and in Harding's document, "Compressed Data for EDIINT".
AS3规范支持通过RFC3274应用程序直接压缩传输的数据。实施细节可以在RFC和Harding的文件“EDIINT压缩数据”中找到。
RFC 959 specifies how data is transferred using the File Transfer Protocol (FTP)
RFC 959指定如何使用文件传输协议（FTP）传输数据
This RFC describes a framework for providing security services to FTP.
本RFC描述了一个为FTP提供安全服务的框架。
This document defines security multiparts for MIME: multipart/encrypted and multipart/signed.
本文档定义了MIME的安全多部分：多部分/加密和多部分/签名。
RFC 3462 defines the use of the multipart/report content type, upon which RFC 3798 builds to define the Message Disposition Notification.
RFC 3462定义了多部分/报告内容类型的使用，RFC 3798基于该类型构建以定义消息处置通知。
This RFC defines the use of content type "application" for ANSI X12 (application/EDI-X12), EDIFACT (application/EDIFACT), and mutually defined EDI (application/EDI-Consent).
本RFC定义了ANSI X12（应用程序/EDI-X12）、EDIFACT（应用程序/EDIFACT）和相互定义的EDI（应用程序/EDI同意）的内容类型“应用程序”的使用。
These are the basic MIME standards, upon which all MIME-related RFCs build, including this one. Key contributions include definitions of "content type", "sub-type", and "multipart", as well as encoding guidelines, which establish 7-bit US-ASCII as the canonical character set to be used in Internet messaging.
这些是基本的MIME标准，所有与MIME相关的RFC都是基于这些标准构建的，包括这个标准。主要贡献包括“内容类型”、“子类型”和“多部分”的定义以及编码准则，这些准则将7位US-ASCII确立为Internet消息传递中使用的规范字符集。
This Internet RFC defines how a Message Disposition Notification (MDN)is requested, as well as the format and syntax of the MDN. The MDN is the vehicle used by this specification to provide both signed and unsigned receipts.
此Internet RFC定义了如何请求消息处置通知（MDN），以及MDN的格式和语法。MDN是本规范用于提供签名和未签名收据的工具。
3.8. RFC 3852: CMS [9] and RFC 3851: S/MIME Version 3.1 Message Specification [10]
3.8. RFC 3852:CMS[9]和RFC 3851:S/MIME版本3.1消息规范[10]
This specification describes how MIME shall carry Cryptographic Message Syntax (CMS) Objects.
本规范描述MIME如何携带加密消息语法（CMS）对象。
RFC 3850 describes certificate handling in the context of CMS and S/MIME.
RFC3850描述了CMS和S/MIME上下文中的证书处理。
3.10. RFC 3274: Compressed Data Content Type for Cryptographic Message Syntax (CMS) [17]
3.10. RFC 3274：加密消息语法（CMS）的压缩数据内容类型[17]
This specification provides a mechanism to wrap compressed data within a CMS object.
该规范提供了一种将压缩数据包装到CMS对象中的机制。
This RFC defines the use of content type "application" for XML. Note that while conforming implementations SHOULD support the expanded syntax that RFC 3023 introduces for the "+xml" suffix, no support for external parsed entity types is anticipated (as it adds significant complexity to signature processing).
此RFC定义了XML的内容类型“应用程序”的使用。请注意，尽管一致性实现应支持RFC 3023为“+xml”后缀引入的扩展语法，但预计不会支持外部解析实体类型（因为它会增加签名处理的复杂性）。
The basic structure of AS3 messages comprises MIME encapsulated data with both customary MIME headers and a few additional AS3-specific outer headers. The structures below are described hierarchically in terms of which RFCs have been applied to form the specific structure. The reader is referred directly to the referenced RFCs for implementation details.
AS3消息的基本结构由MIME封装的数据组成，其中既有常用的MIME头，也有一些附加的AS3特定的外部头。下面的结构按照应用RFC形成特定结构的层次进行描述。读者可直接参考参考的RFC了解实施细节。
Any additional restrictions imposed by this AS are specifically discussed in the sections that follow.
本协议施加的任何附加限制将在以下章节中具体讨论。
No encryption, no signature
没有加密，没有签名
-RFC822/2045
-RFC1767/RFC2376 (application/EDIxxxx or /xml)
-RFC822/2045
-RFC1767/RFC2376 (application/EDIxxxx or /xml)
No encryption, signature
没有加密，没有签名
-RFC822/2045
-RFC1847 (multipart/signed)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)
-RFC3851 (application/pkcs7-signature)
-RFC822/2045
-RFC1847 (multipart/signed)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)
-RFC3851 (application/pkcs7-signature)
Encryption, no signature
加密，无签名
-RFC822/2045
-RFC3851 (application/pkcs7-mime)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
-RFC822/2045
-RFC3851 (application/pkcs7-mime)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
Encryption, signature
加密、签名
-RFC822/2045
-RFC3851 (application/pkcs7-mime)
-RFC1847 (multipart/signed)(encrypted)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
-RFC3851 (application/pkcs7-signature)(encrypted)
-RFC822/2045
-RFC3851 (application/pkcs7-mime)
-RFC1847 (multipart/signed)(encrypted)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
-RFC3851 (application/pkcs7-signature)(encrypted)
MDN, no signature
MDN，没有签名
-RFC822/2045 -RFC3798 (message/disposition-notification)
-RFC822/2045-RFC3798（消息/处置通知）
MDN, signature
签名
-RFC822/2045
-RFC1847 (multipart/signed)
-RFC3798 (message/disposition-notification)
-RFC3851 (application/pkcs7-signature)
-RFC822/2045
-RFC1847 (multipart/signed)
-RFC3798 (message/disposition-notification)
-RFC3851 (application/pkcs7-signature)
While all MIME content types SHOULD be supported, the following MIME content types MUST be supported:
虽然应支持所有MIME内容类型，但必须支持以下MIME内容类型：
Content-Type: multipart/signed
Content-Type: multipart/report
Content-type: message/disposition-notification
Content-Type: application/PKCS7-signature
Content-Type: application/PKCS7-mime
Content-Type: application/EDI-X12
Content-Type: application/EDIFACT
Content-Type: application/edi-consent
Content-Type: application/XML
Content-Type: multipart/signed
Content-Type: multipart/report
Content-type: message/disposition-notification
Content-Type: application/PKCS7-signature
Content-Type: application/PKCS7-mime
Content-Type: application/EDI-X12
Content-Type: application/EDIFACT
Content-Type: application/edi-consent
Content-Type: application/XML
The AS3-From and AS3-To headers have been provided to assist the sender and the recipient of an EC document to identify each other:
已提供AS3 From和AS3 To标题，以帮助EC文件的发件人和收件人相互识别：
AS3-From: < AS3-name >
AS3-To: < AS3-name >
AS3-From: < AS3-name >
AS3-To: < AS3-name >
These headers contain textual values, described by the ABNF [22] below, identifying the sender/receiver of a data exchange. A value may be company specific (e.g., a Data Universal Numbering System (DUNS) number), or it may be simply some string mutually acceptable to both trading partners used to identify each to the other.
这些标题包含文本值，由下面的ABNF[22]描述，用于标识数据交换的发送方/接收方。值可以是特定于公司的（例如，数据通用编号系统（DUNS）编号），也可以是两个贸易伙伴共同接受的字符串，用于相互识别。
AS3-text = "!" / ; printable ASCII characters
%d35-91 / ; except double-quote (%d34)
%d93-126 ; or backslash (%d92)
AS3-text = "!" / ; printable ASCII characters
%d35-91 / ; except double-quote (%d34)
%d93-126 ; or backslash (%d92)
AS3-qtext = AS3-text / SP ; allow space only in quoted text
AS3-qtext = AS3-text / SP ; allow space only in quoted text
AS3-quoted-pair = "\" DQUOTE / ; \" or
"\" "\" ; \\
AS3-quoted-pair = "\" DQUOTE / ; \" or
"\" "\" ; \\
AS3-quoted-name = DQUOTE 1*128( AS3-qtext /
AS3-quoted-pair) DQUOTE
AS3-quoted-name = DQUOTE 1*128( AS3-qtext /
AS3-quoted-pair) DQUOTE
AS3-atomic-name = 1*128AS3-text
AS3-atomic-name = 1*128AS3-text
AS3-name = AS3-atomic-name / AS3-quoted-name
AS3-name = AS3-atomic-name / AS3-quoted-name
Note: SP and DQUOTE are defined in [ABNF]RFC 4234.
注：SP和DQUOTE在[ABNF]RFC 4234中定义。
The AS3-From header value and the AS3-To header value MUST each be an AS3-name comprising 1 to 128 printable ASCII characters. The header MUST NOT be folded, and the value for each of these headers is case-sensitive.
AS3 From标头值和AS3 To标头值必须分别为AS3名称，由1到128个可打印ASCII字符组成。标题不得折叠，并且每个标题的值区分大小写。
The AS3-quoted-name SHOULD be used only if the AS3-name does not conform to AS3-atomic-name.
仅当AS3名称与AS3原子名称不一致时，才应使用AS3引用名称。
The AS3-To and AS3-From header fields MUST be present in all AS3 messages and AS3 MDNs.
AS3 To和AS3 From标头字段必须出现在所有AS3消息和AS3 MDN中。
Implementations that map entities such as EDI identifiers/qualifiers to AS3 identifiers may choose to constrain the set of AS3-To/AS3-From text values to a subset of the full set defined above, but they may not extend that set.
将实体（如EDI标识符/限定符）映射到AS3标识符的实现可以选择将AS3到AS3的集合从文本值约束到上面定义的完整集合的子集，但它们可能不会扩展该集合。
If the AS3-From or the AS3-To or the association of the two header values is determined to be invalid or unknown to the receiving system, the receiving system MAY respond with an unsigned MDN containing an explanation of the error if the sending system requested an MDN, but it is not required to return an MDN under those circumstances.
如果AS3 From或AS3 To或两个报头值的关联被确定为无效或接收系统未知，则如果发送系统请求MDN，接收系统可以使用包含错误解释的未签名MDN进行响应，但在这些情况下不需要返回MDN。
The AS3-Version header is a header that is required only if the value of the header is not "1.0". Its purpose is to allow systems to determine which version of this specification (should the specification evolve over time) the sender of a document has used to
AS3版本头是仅当头的值不是“1.0”时才需要的头。其目的是允许系统确定文档的发送者使用了本规范的哪个版本（如果规范随着时间的推移而演变）
package the document. A user agent MUST NOT reject a message if the version header is missing.
打包文档。如果缺少版本标头，则用户代理不得拒绝消息。
AS3-Version: 1*DIGIT . 1*DIGIT
AS3-Version: 1*DIGIT . 1*DIGIT
A version header value of "1.1" indicates an implementation can support EDIINT data compression [20]. A user agent MUST NOT send compressed messages to trading partners who do not use a version header of "1.1" or greater.
版本头值“1.1”表示实现可以支持EDIINT数据压缩[20]。用户代理不得向未使用“1.1”或更高版本标题的贸易伙伴发送压缩消息。
FTP has long been viewed as an insecure protocol primarily because of its use of cleartext authentication [3]. This is addressed by RFC 2228 [4], and the use of one of the security mechanisms described therein is strongly encouraged. Specifically, conforming implementations of AS3 SHALL employ FTP client/servers that support the AUTH command described within [4]. While any authentication mechanism based upon [4] MAY be utilized, AUTH TLS (as described in [18]) MUST be supported. (Note that [18] relies on TLS Version 1.0 [13], not Version 1.1 [23].)
FTP长期以来一直被视为一种不安全的协议，主要是因为它使用了明文身份验证[3]。RFC 2228[4]解决了这一问题，强烈鼓励使用其中描述的一种安全机制。具体而言，AS3的一致性实现应采用支持[4]中所述AUTH命令的FTP客户端/服务器。虽然可以使用基于[4]的任何身份验证机制，但必须支持身份验证TLS（如[18]中所述）。（请注意，[18]依赖TLS版本1.0[13]，而不是版本1.1[23]。）
Large files are handled correctly by the TCP layer. However, the mechanism for compressing data, referenced in Section 2.4.2.2, efficiently reduces transmission requirements for many data types (including both XML and traditional EDI data). Additionally, some FTP implementations support compression as well.
大型文件由TCP层正确处理。但是，第2.4.2.2节中引用的数据压缩机制有效地降低了许多数据类型（包括XML和传统EDI数据）的传输要求。此外，一些FTP实现还支持压缩。
An AS3 message MUST contain the following outer headers:
AS3消息必须包含以下外部标头：
AS3-To AS3-From Date Message-ID Content-Type
AS3至AS3起始日期消息ID内容类型
An AS3 message OPTIONALLY MAY contain the following outer headers:
AS3消息可以选择包含以下外部标头：
Subject AS3-Version (assumed to be 1.0 if not present) Content-Length
主题AS3版本（如果不存在，则假定为1.0）内容长度
An AS3 message requesting a receipt MUST contain a Disposition-Notification-To header and MAY contain a Disposition-Notification-Options header (if the receipt is to be signed).
请求收据的AS3消息必须包含处置通知标题，并且可能包含处置通知选项标题（如果要签署收据）。
Additional headers MAY be present but are ignored.
可能存在其他标题，但会被忽略。
FTP defines several data structures and character encodings via the STRU[cture] and TYPE commands. AS3 requires the file-structure (default) and the image type. The Content-Transfer-Encoding header SHOULD NOT be used; if the header is present, it SHOULD have a value of binary or 8-bit. The absence of this header or the use of alternate values such as "base64" or "quoted-printable" MUST NOT result in transaction failure. Content transfer encoding of MIME parts within the AS3 message are similarly constrained.
FTP通过STRU[cture]和TYPE命令定义了几种数据结构和字符编码。AS3需要文件结构（默认）和图像类型。不应使用内容传输编码头；如果存在标头，则其值应为二进制或8位。缺少此标题或使用替代值（如“base64”或“quoted printable”）不得导致事务失败。AS3消息中MIME部分的内容传输编码也受到类似的约束。
A MIME message containing an epilogue [1] SHALL NOT be used.
不得使用包含尾声[1]的MIME消息。
Message-Id and Original-Message-Id are formatted as defined in Section 3.6.4 of RFC 2822 [15]: "<" id-left "@" id-right ">". Message-Id length is a maximum of 998 characters. Message-Id SHOULD be globally unique; id-right should be something unique to the sending host environment (e.g., a host name). When sending a message, always include the angle brackets. Angle brackets are not part of the Message-Id value.
消息Id和原始消息Id的格式如RFC 2822[15]第3.6.4节所述：“<“Id left”@“Id right”>”。消息Id长度最多为998个字符。消息Id应该是全局唯一的；id权限应该是发送主机环境特有的内容（例如，主机名）。发送消息时，请始终使用尖括号。尖括号不是消息Id值的一部分。
NOTE: When creating the Original-Message-Id header in an MDN, always use the exact syntax contained in the original message: do not strip or add "angle brackets".
注意：在MDN中创建原始消息Id头时，始终使用原始消息中包含的确切语法：不要去掉或添加“尖括号”。
In order to support non-repudiation of receipt, a signed receipt, based on digitally signing a message disposition notification, is to be implemented by a receiving trading partner's UA. The message disposition notification specified by RFC 3798 is digitally signed by a receiving trading partner as part of a multipart/signed MIME message.
为了支持收据的不可否认性，接收交易伙伴的UA将实现基于对消息处置通知进行数字签名的签名收据。RFC 3798指定的消息处置通知由接收交易伙伴作为多部分/签名MIME消息的一部分进行数字签名。
The following support for signed receipts is REQUIRED:
需要对签名收据提供以下支持：
1) The ability to create a multipart/report; where the report-type = disposition-notification.
1) 创建多部分/报告的能力；其中，报告类型=处置通知。
2) The ability to calculate a message integrity check (MIC) on the received message. The calculated MIC value will be returned to the sender of the message inside the signed receipt.
2) 对接收到的消息计算消息完整性检查（MIC）的能力。计算出的MIC值将返回给已签名回执内的邮件发件人。
3) The ability to create a multipart/signed content with the message disposition notification as the first body part, and the signature as the second body part.
3) 创建多部分/签名内容的能力，其中消息处置通知作为第一个正文部分，签名作为第二个正文部分。
4) The ability to return the signed receipt to the sending trading partner.
4) 能够将签署的收据返回给发送交易伙伴。
The signed receipt is used to notify a sending trading partner that requested the signed receipt that:
签字收据用于通知请求签字收据的发送交易伙伴：
1) The receiving trading partner acknowledges receipt of the sent EC Interchange.
1) 接收交易伙伴确认收到已发送的EC交换。
2) If the sent message was signed, then the receiving trading partner has authenticated the sender of the EC Interchange.
2) 如果发送的消息已签名，则接收交易伙伴已验证EC交换的发送方。
3) If the sent message was signed, then the receiving trading partner has verified the integrity of the sent EC Interchange.
3) 如果发送的消息已签名，则接收交易伙伴已验证发送的EC交换的完整性。
Regardless of whether the EDI/EC Interchange was sent in S/MIME format or not, the receiving trading partner's UA MUST provide the following basic processing:
无论EDI/EC交换是否以S/MIME格式发送，接收交易伙伴的UA必须提供以下基本处理：
1) If the sent EDI/EC Interchange is encrypted, then the encrypted symmetric key, and initialization vector (if applicable) is decrypted using the receiver's private key.
1) 如果发送的EDI/EC交换是加密的，则使用接收方的私钥对加密的对称密钥和初始化向量（如果适用）进行解密。
2) The decrypted symmetric encryption key is then used to decrypt the EDI/EC Interchange.
2) 然后使用解密的对称加密密钥对EDI/EC交换进行解密。
3) The receiving trading partner authenticates signatures in a message using the sender's public key.
3) 接收交易伙伴使用发送方的公钥对消息中的签名进行身份验证。
The authentication algorithm performs the following:
身份验证算法执行以下操作：
a) The message integrity check (MIC or Message Digest) is decrypted using the sender's public key.
a) 消息完整性检查（MIC或消息摘要）使用发送方的公钥解密。
b) A MIC on the signed contents (the MIME header and encoded EDI object, as per RFC 1767) in the message received is calculated using the same one-way hash function that the sending trading partner used.
b) 使用发送交易伙伴使用的同一单向散列函数计算接收到的消息中签名内容（MIME头和编码EDI对象，根据RFC 1767）上的MIC。
c) The MIC extracted from the message that was sent and the MIC calculated using the same one-way hash function that the sending trading partner used are compared for equality.
c) 将从发送的消息中提取的MIC与使用发送交易伙伴使用的同一单向散列函数计算的MIC进行相等性比较。
4) The receiving trading partner formats the MDN and sets the calculated MIC into the "Received-content-MIC" extension field.
4) 接收交易伙伴格式化MDN，并将计算的MIC设置为“接收内容MIC”扩展字段。
5) The receiving trading partner creates a multipart/signed MIME message according to RFC 1847.
5) 接收交易伙伴根据RFC 1847创建多部分/签名MIME消息。
6) The MDN is the first part of the multipart/signed message, and the digital signature is created over this MDN, including its MIME headers.
6) MDN是多部分/签名消息的第一部分，数字签名是在此MDN上创建的，包括其MIME头。
7) The second part of the multipart/signed message contains the digital signature. The "protocol" option specified in the second part of the multipart/signed is as follows: S/MIME: protocol = "application/pkcs7-signature".
7) 多部分/签名消息的第二部分包含数字签名。在multipart/signed第二部分中指定的“协议”选项如下：S/MIME:protocol=“application/pkcs7 signature”。
8) The signature information is formatted according to S/MIME specifications. The EC Interchange and the RFC 1767 MIME EDI content header can actually be part of a multipart MIME content type. When the EDI Interchange is part of a multipart MIME content type, the MIC MUST be calculated across the entire multipart content, including the MIME headers.
8) 签名信息根据S/MIME规范格式化。EC交换和RFC1767 MIME EDI内容头实际上可以是多部分MIME内容类型的一部分。当EDI交换是多部分MIME内容类型的一部分时，必须跨整个多部分内容（包括MIME头）计算MIC。
The signed MDN, when received by the sender of the EDI Interchange can be used by the sender:
当EDI交换的发送方收到签名的MDN时，发送方可以使用：
1) As an acknowledgment that the EDI Interchange was sent, and then was delivered and acknowledged by the receiving trading partner.
1) 确认EDI交换已发送，然后由接收交易伙伴交付和确认。
The receiver does this by returning the original-message-id of the sent message in the MDN portion of the signed receipt.
接收方通过在签名收据的MDN部分中返回已发送消息的原始消息id来完成此操作。
2) As an acknowledgment that the integrity of the EDI Interchange was verified by the receiving trading partner. The receiver does this by returning the calculated MIC of the received EC Interchange (and 1767 MIME headers) in the "Received-content-MIC" field of the signed MDN.
2) 作为对EDI交换完整性已由接收贸易伙伴验证的确认。接收机通过在签名MDN的“received content MIC”字段中返回已接收EC交换（和1767 MIME头）的计算MIC来实现这一点。
3) As an acknowledgment that the receiving trading partner has authenticated the sender of the EDI Interchange.
3) 作为接收交易伙伴已认证EDI交换发送方的确认。
4) As a non-repudiation of receipt when the signed MDN is successfully verified by the sender with the receiving trading partner's public key and the returned MIC value inside the MDN is the same as the digest of the original message.
4) 当发送方使用接收交易伙伴的公钥成功验证已签名的MDN，并且MDN内返回的MIC值与原始消息摘要相同时，作为不可否认的接收。
The AS3-MDNs are returned on a separate FTP TCP/IP connection and are a response to an AS3 message.
AS3 MDN通过单独的FTP TCP/IP连接返回，是对AS3消息的响应。
The following diagram illustrates the delivery of an AS3-MDN delivery:
下图说明了AS3-MDN交付的交付：
AS3-MDN
[S] ----( connect )----> [R] [FTP Server]
[S] ----( send )-------> [R] [AS3-Message]
[S] ----( disconnect )-> [R] [FTP Server]
AS3-MDN
[S] ----( connect )----> [R] [FTP Server]
[S] ----( send )-------> [R] [AS3-Message]
[S] ----( disconnect )-> [R] [FTP Server]
[S] <---( connect )----- [R] [FTP Server]
[S] <---( send )-------- [R] [AS3-MDN]]
[S] <---( disconnect )-- [R] [FTP Server]
[S] <---( connect )----- [R] [FTP Server]
[S] <---( send )-------- [R] [AS3-MDN]]
[S] <---( disconnect )-- [R] [FTP Server]
Note: Refer to Section 7.4.4 for additional programming notes.
注：有关其他编程说明，请参阅第7.4.4节。
Message Disposition Notifications are requested as per RFC 3798. A request that the receiving user agent issue a message disposition notification is made by placing the following header into the message to be sent:
根据RFC 3798请求消息处置通知。通过将以下标头放入要发送的消息中，请求接收用户代理发出消息处置通知：
MDN-request-header = "Disposition-notification-to" ":" ftpurl
MDN请求头=“处置通知到”“：”ftpurl
This syntax is a residual of the use of MDN's in an SMTP transfer. Since this specification is adjusting the functionality from SMTP to
此语法是在SMTP传输中使用MDN的剩余语法。由于此规范正在将功能从SMTP调整为
FTP and retaining as much as possible from the [5] functionality, the ftpurl must be present.
FTP和保留尽可能多的[5]功能，ftpurl必须存在。
The ftpurl field is specified as an RFC 1738 <URL:"ftp://" login [ "/" fpath [ ";type=" ftptype ]]>, and while it MUST be present, it may be ignored if the ftpurl points to an unknown location. If the ftpurl points to an unknown location, it is RECOMMENDED that the mdn is returned back to a known ftpurl for the sender of the received message.
ftpurl字段被指定为RFC 1738<URL:“ftp://”login[“/”fpath[”；type=“ftptype]]>，虽然它必须存在，但如果ftpurl指向未知位置，它可能会被忽略。如果ftpurl指向未知位置，建议将mdn返回到接收消息的发送方的已知ftpurl。
For requesting MDN-based receipts, the originator supplies the required extension headers that precede the message body.
对于请求基于MDN的回执，发起者提供消息正文之前所需的扩展标题。
The header "tags" are as follows:
标题“标签”如下所示：
A Disposition-notification-to header is added to indicate that a message disposition notification is requested. This header is specified in [6].
添加到标头的处置通知，以指示请求了消息处置通知。此标题在[6]中指定。
A Message-ID header is added to support message reconciliation, so that an Original-Message-Id value can be returned in the body part of the MDN.
添加消息ID头以支持消息协调，因此可以在MDN的主体部分返回原始消息ID值。
Other headers, especially "Date", SHOULD be supplied; the values of these headers are often mentioned in the human-readable section of an MDN to aid in identifying the original message.
应提供其他标题，尤其是“日期”；MDN的可读部分经常提到这些头的值，以帮助识别原始消息。
Disposition-notification-options identifies characteristics of the message.
处置通知选项标识消息的特征。
The following Disposition notification is in accordance with [6].
以下处置通知符合[6]。
EXAMPLE:
Disposition-notification-to: // Requests the MDN
ftp://host:port/inbox // Location to return MDN
Disposition-notification-options: // The signing options for
MDN
signed-receipt-protocol=optional, pkcs7-signature;
signed-receipt-micalg=optional, sha1, md5
EXAMPLE:
Disposition-notification-to: // Requests the MDN
ftp://host:port/inbox // Location to return MDN
Disposition-notification-options: // The signing options for
MDN
signed-receipt-protocol=optional, pkcs7-signature;
signed-receipt-micalg=optional, sha1, md5
Disposition-notification-options syntax:
处置通知选项语法：
Disposition-notification-options = "Disposition-Notification-Options:" disposition-notification-parameters
处置通知选项=“处置通知选项：”处置通知参数
disposition-notification-parameters = parameter *(";" parameter)
处置通知参数=参数*（“；”参数）
parameter = attribute "=" importance ", " value *("," value)
parameter = attribute "=" importance ", " value *("," value)
importance = "required" / "optional"
importance = "required" / "optional"
attribute = "signed-receipt-protocol" / "signed-receipt-micalg"
attribute = "signed-receipt-protocol" / "signed-receipt-micalg"
So the Disposition-notification-options string could be:
因此，处置通知选项字符串可以是：
signed-receipt-protocol=optional, <protocol symbol>;
signed-receipt-micalg=optional, <micalg1>, <micalg2>,...;
signed-receipt-protocol=optional, <protocol symbol>;
signed-receipt-micalg=optional, <micalg1>, <micalg2>,...;
The currently supported value for <protocol symbol> is "pkcs7- signature" for the S/MIME detached signature format.
对于S/MIME分离签名格式，<protocol symbol>当前支持的值是“pkcs7-signature”。
The currently supported values for MIC algorithm <micalg> values are:
MIC算法<micalg>值当前支持的值为：
Algorithm Value
Used
-------- -------
MD5 md5
SHA-1 sha1
Algorithm Value
Used
-------- -------
MD5 md5
SHA-1 sha1
Receiving agents SHOULD be able to recover gracefully from a <micalg> parameter value that they do not recognize.
接收代理应该能够从它们无法识别的<micalg>参数值中正常恢复。
The semantics of the "signed-receipt-protocol" parameter is as follows:
“签名接收协议”参数的语义如下：
1) The "signed-receipt-protocol" parameter is used to request a signed receipt from the recipient trading partner. The "signed-receipt-protocol" parameter also specifies the format in which the signed receipt should be returned to the requester.
1) “签名收据协议”参数用于向接收方交易伙伴请求签名收据。“签名收据协议”参数还指定签名收据应返回给请求者的格式。
The "signed-receipt-micalg" parameter is a list of MIC algorithms preferred by the requester for use in signing the returned receipt and calculating the micalg in the Received-content-MIC header.
“signed receipt micalg”参数是请求者首选的MIC算法列表，用于签署返回的收据和计算接收内容MIC头中的micalg。
The list of MIC algorithms should be honored by the recipient from left to right. Both the "signed-receipt-protocol" and the "signed-receipt-micalg" option parameters are REQUIRED when requesting a signed receipt.
MIC算法列表应由接收者从左到右执行。请求签名收据时，需要“签名收据协议”和“签名收据micalg”选项参数。
2) The "importance" attribute of "Optional" is defined in RFC 3798, Section 2.2, and has the following meaning:
2) RFC 3798第2.2节定义了“可选”的“重要性”属性，其含义如下：
Parameters with an importance of "Optional" permit a UA that does not understand the particular options parameter to still generate an MDN in response to a request for an MDN. A UA that does not
重要性为“可选”的参数允许不了解特定选项参数的UA仍然生成MDN以响应MDN请求。一个没有
understand the "signed-receipt-protocol" parameter, or the "signed-receipt-micalg" parameter, will obviously not return a signed receipt.
理解“签名收据协议”参数或“签名收据micalg”参数显然不会返回签名收据。
The importance of "Optional" is used for the signed receipt parameters because it is RECOMMENDED that an MDN be returned to the requesting trading partner even if the recipient could not sign it.
“可选”的重要性用于签名收据参数，因为建议将MDN返回给请求交易伙伴，即使收件人无法签名。
The returned MDN will contain information on the disposition of the message as well as on why the MDN could not be signed. See the Disposition field in Section 7.5 for more information.
返回的MDN将包含有关消息处置的信息以及无法对MDN进行签名的原因。有关更多信息，请参见第7.5节中的处置字段。
Within an EDI trading relationship, if a signed receipt is expected and is not returned, then the validity of the transaction must be determined by the trading partners. Typically, if a signed receipt is required by the trading relationship and is not received, the transaction will likely not be considered valid.
在电子数据交换交易关系中，如果预期会有一份已签署的收据，但没有返回，则交易的有效性必须由交易伙伴确定。通常，如果交易关系要求签署收据，但未收到，则该交易可能被视为无效。
The method used to request a receipt or a signed receipt is defined in RFC 3798, "An Extensible Message Format for Message Disposition Notifications".
RFC 3798“用于消息处置通知的可扩展消息格式”中定义了用于请求收据或签名收据的方法。
The "rules" for processing a receipt-request follow:
处理接收请求的“规则”如下：
1) When a receipt is requested, explicitly specifying that the receipt be signed, then the receipt MUST be returned with a signature unless conditions (2) or (3) below are applicable.
1) 当要求提供收据时，明确规定必须签署收据，则除非以下条件（2）或（3）适用，否则必须随签名一起返回收据。
2) When a receipt is requested, explicitly specifying that the receipt be signed, but the recipient cannot support either the requested protocol format, or requested MIC algorithms, then either a signed or unsigned receipt SHOULD be returned.
2) 当请求收据时，明确指定要对收据进行签名，但收件人无法支持请求的协议格式或请求的MIC算法，则应返回已签名或未签名的收据。
3) When a receipt is requested, explicitly specifying that the receipt be signed, but the recipient is unable to compute the digest (e.g., message was encrypted, and recipient unable to decrypt), then the recipient SHOULD NOT return "Received-content-MIC" in the MDN to the requestor. If the MDN sets the disposition (e.g., "processed/error: decryption-failed") appropriately, then the "Received-content-MIC" may be returned, but the value must be discarded.
3) 当请求收据时，明确指定要签署收据，但收件人无法计算摘要（例如，邮件已加密，收件人无法解密），则收件人不应将MDN中的“已接收内容MIC”返回给请求者。如果MDN适当地设置了处置（例如，“已处理/错误：解密失败”），则可以返回“已接收内容MIC”，但必须丢弃该值。
4) When a signature is not explicitly requested, or if the signed receipt request parameter is not recognized by the UA, then no receipt, an unsigned receipt, or a signed receipt MAY be returned by the recipient.
4) 如果未明确请求签名，或者UA无法识别签名收据请求参数，则收件人可能不会返回收据、未签名收据或签名收据。
5) If a message is received without a request for a receipt, then a receipt (signed or unsigned) MAY be returned.
5) 如果收到消息时未请求回执，则可能会返回回执（已签名或未签名）。
The "Received-content-MIC" MUST be calculated as follows:
“接收内容MIC”必须按以下方式计算：
- For any signed messages, the MIC to be returned is calculated on the RFC 1767 MIME header and content. Canonicalization as specified in RFC 1848 MUST be performed before the MIC is calculated, since the sender requesting the signed receipt was also REQUIRED to canonicalize.
- 对于任何已签名的消息，将根据RFC1767 MIME头和内容计算要返回的MIC。RFC 1848中规定的规范化必须在计算MIC之前执行，因为请求签名收据的发送方也需要规范化。
- For encrypted, unsigned messages, the MIC to be returned is calculated on the decrypted RFC 1767 MIME header and content. The content after decryption MUST be canonicalized before the MIC is calculated.
- 对于加密的、未签名的消息，将根据解密的RFC1767 MIME头和内容计算要返回的MIC。解密后的内容必须在计算MIC之前规范化。
- For unsigned, un-encrypted messages, the MIC MUST be calculated over the message contents prior to Content-Transfer-Encoding and without the MIME or any other RFC 822 [14] headers, since these are sometimes altered or reordered by message transfer agents (MTAs).
- 对于未签名、未加密的邮件，在内容传输编码之前，必须在邮件内容上计算MIC，并且不使用MIME或任何其他RFC 822[14]头，因为邮件传输代理（MTA）有时会更改或重新排序这些头。
This section defines the format of the AS3 Message Disposition Notification (AS3-MDN).
本节定义了AS3消息处置通知（AS3-MDN）的格式。
The AS3-MDN follows the MDN specification [6] except where noted in this section. The modified entity definitions in this document use the vertical-bar character, '|', to denote a logical "OR" construction. Refer to RFC 2045 for the format of MIME-message-headers.
AS3-MDN遵循MDN规范[6]，除非本节另有说明。本文档中修改的实体定义使用竖线字符“|”，表示逻辑“或”结构。有关MIME消息头的格式，请参阅RFC 2045。
The format of the AS3-MDN is
AS3-MDN的格式为
MDN, no signature
MDN，没有签名
-RFC822/2045 -RFC3798 (message/disposition-notification)
-RFC822/2045-RFC3798（消息/处置通知）
MDN, signature
签名
-RFC822/2045
-RFC1847 (multipart/signed)
-RFC3798 (message/disposition-notification)
-RFC3851 (application/pkcs7-signature)
-RFC822/2045
-RFC1847 (multipart/signed)
-RFC3798 (message/disposition-notification)
-RFC3851 (application/pkcs7-signature)
The AS3-MDN-body is formatted as a MIME multipart/report with a report-type of "disposition-notification".
AS3 MDN正文的格式为MIME多部分/报告，报告类型为“处置通知”。
When unsigned, the transfer-layer ("outermost") entity-headers of the AS3-MDN contain the Content-Type header that specifies a content type of "multipart/report", parameters indicating the report-type, and the value of the outermost multipart boundary.
未签名时，AS3-MDN的传输层（“最外层”）实体标头包含内容类型标头，该标头指定“多部分/报告”的内容类型、指示报告类型的参数以及最外层多部分边界的值。
When the AS3-MDN is signed, the transfer-layer ("outermost") entity-headers of the AS3-MDN contain a Content-Type header that specifies a content type of "multipart/signed", parameters indicating the algorithm used to compute the message digest, the signature formatting protocol (e.g., pkcs7-signature), and the value of the outermost multipart boundary. The first part of the MIME multipart/signed message is an imbedded MIME multipart/report of type "disposition-notification". The second part of the multipart/signed message contains a MIME application/pkcs7-signature message.
对AS3-MDN进行签名时，AS3-MDN的传输层（“最外层”）实体标头包含一个内容类型标头，该标头指定“多部分/签名”的内容类型，参数指示用于计算消息摘要的算法、签名格式协议（例如pkcs7签名），和最外面的多部分边界的值。MIME多部分/签名消息的第一部分是“处置通知”类型的嵌入MIME多部分/报告。多部分/签名消息的第二部分包含MIME应用程序/pkcs7签名消息。
The first part of the MIME multipart/report is a "human-readable" portion that contains a general description of the message disposition. The second part of the MIME multipart/report is a "machine-readable" portion that is defined as
MIME多部分/报告的第一部分是“人类可读”部分，包含消息处理的一般描述。MIME多部分/报告的第二部分是“机器可读”部分，定义为
AS3-disposition-notification-content =
[ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ]
[ original-recipient-field CRLF ]
final-recipient-field CRLF
[ original-message-id-field CRLF ]
AS3-disposition-field CRLF
*( failure-field CRLF )
*( error-field CRLF )
*( warning-field CRLF )
*( extension-field CRLF )
[ AS3-received-content-MIC-field CRLF ]
AS3-disposition-notification-content =
[ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ]
[ original-recipient-field CRLF ]
final-recipient-field CRLF
[ original-message-id-field CRLF ]
AS3-disposition-field CRLF
*( failure-field CRLF )
*( error-field CRLF )
*( warning-field CRLF )
*( extension-field CRLF )
[ AS3-received-content-MIC-field CRLF ]
It is noted that several of the optional fields defined by RFC 3798 and shown above are not relevant to a point-to-point transport such as FTP and would not normally appear in an AS3 MDN.
需要注意的是，RFC 3798定义的和上面显示的几个可选字段与点到点传输（如FTP）无关，通常不会出现在AS3 MDN中。
The rules for constructing the AS3-disposition-notification-content are identical to the rules for constructing the disposition-notification-content as defined in Section 7 of RFC 3798 [6] except that the RFC 3798 disposition-field has been replaced with the AS3- disposition-field and that the AS3-received-content-MIC field has been added. The differences between the RFC 3798 disposition-field and the AS3-disposition-field are described below. Where there are differences between this document and RFC 3798, those entity names have been changed by prepending "AS3-". Entities below that do not differ from RFC 3798 are not necessarily further defined in this document.
构建AS3处置通知内容的规则与RFC 3798[6]第7节中定义的构建处置通知内容的规则相同，但RFC 3798处置字段已替换为AS3-处置字段，并且已添加AS3接收内容MIC字段。RFC 3798处置字段和AS3处置字段之间的差异如下所述。如果本文件与RFC 3798之间存在差异，则已通过在“AS3-”前面加上前缀来更改这些实体名称。以下与RFC 3798没有区别的实体不必在本文件中进一步定义。
Refer to RFC 3798 [6] and RFC 4234 [22] for entities that are not further defined in this document.
关于本文件中未进一步定义的实体，请参考RFC 3798[6]和RFC 4234[22]。
AS3-disposition-field = "Disposition:" disposition-mode ";"
AS3-disposition-type [ "/" AS3-disposition-modifier]
AS3-disposition-field = "Disposition:" disposition-mode ";"
AS3-disposition-type [ "/" AS3-disposition-modifier]
disposition-mode = action-mode "/" sending-mode
处置模式=行动模式“/”发送模式
action-mode = "manual-action" / "automatic-action"
action-mode = "manual-action" / "automatic-action"
sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
AS3-disposition-type = "processed" / "failed"
AS3-disposition-type = "processed" / "failed"
AS3-disposition-modifier = ( "error" / "warning" ) /
AS3-disposition-modifier-extension
AS3-disposition-modifier = ( "error" / "warning" ) /
AS3-disposition-modifier-extension
AS3-disposition-modifier-extension =
"error: authentication-failed" /
"error: decompression-failed" /
"error: decryption-failed" /
"error: insufficient-message-security" /
"error: integrity-check-failed" /
"error: unexpected-processing-error" /
"warning: " AS3-MDN-warning-description /
"failure: " AS3-MDN-failure-description
AS3-disposition-modifier-extension =
"error: authentication-failed" /
"error: decompression-failed" /
"error: decryption-failed" /
"error: insufficient-message-security" /
"error: integrity-check-failed" /
"error: unexpected-processing-error" /
"warning: " AS3-MDN-warning-description /
"failure: " AS3-MDN-failure-description
AS3-MDN-warning-description = *( TEXT )
AS3-MDN-warning-description = *( TEXT )
AS3-MDN-failure-description = *( TEXT )
AS3-MDN-failure-description = *( TEXT )
AS3-received-content-MIC-field = "Received-content-MIC:" encoded-message-digest "," digest-alg-id CRLF
AS3 received content MIC field=“received content MIC:“编码消息摘要”，“摘要alg id CRLF”
encoded-message-digest =
1*( ALPHA / DIGIT / "/" / "+" ) *3"="
;( i.e. base64( message-digest ) )
encoded-message-digest =
1*( ALPHA / DIGIT / "/" / "+" ) *3"="
;( i.e. base64( message-digest ) )
digest-alg-id = "sha1" / "md5"
digest-alg-id = "sha1" / "md5"
The "Received-content-MIC" extension field is set after the integrity of the received message is verified. The MIC is the base64-encoded message-digest computed over the received message with a hash function. This field is required for signed receipts but optional for unsigned receipts. For details defining the specific content over which the message-digest is to be computed, see Section 7.3.1 of this document.
“Received content MIC”（接收内容麦克风）扩展字段在验证接收消息的完整性后设置。MIC是使用哈希函数对接收到的消息计算的base64编码消息摘要。此字段对于已签名的收据是必需的，但对于未签名的收据是可选的。有关定义用于计算消息摘要的特定内容的详细信息，请参阅本文件第7.3.1节。
The algorithm used to calculate the message digest MUST be the same as the "micalg" value used by the sender in the multipart/signed message. When no signature is received, the message-digest MUST be calculated using the algorithm specified by the "micalg" value in the Disposition-Notification-Options header. When no signature is received and no micalg parameter is provided, then the SHA-1 algorithm MUST be used to calculate the digest. This field is set only when the contents of the message are processed successfully. This field is used in conjunction with the recipient's signature on the MDN in order for the sender to verify non-repudiation of receipt.
用于计算消息摘要的算法必须与发送方在多部分/签名消息中使用的“micalg”值相同。当未收到签名时，必须使用处置通知选项标头中“micalg”值指定的算法计算消息摘要。如果未收到签名且未提供micalg参数，则必须使用SHA-1算法来计算摘要。此字段仅在成功处理消息内容时设置。此字段与收件人在MDN上的签名一起使用，以便发件人验证收据的不可否认性。
AS3-MDN field names (e.g., "Disposition:", "Final-Recipient:") are case-insensitive (cf. RFC 3798, Section 3.1.1).
AS3-MDN字段名（例如，“处置：”、“最终收件人：”）不区分大小写（参见RFC 3798，第3.1.1节）。
AS3-MDN action-modes, sending-modes, AS3-disposition-types, and AS3- disposition-modifier values that are defined above, and user-supplied *( TEXT ) values are also case-insensitive. AS3 implementations MUST NOT make assumptions regarding the values supplied for AS3-MDN-warning-description or AS3-MDN-failure-description or for the values of any (optional) error, warning, or failure fields.
上面定义的AS3-MDN操作模式、发送模式、AS3处置类型和AS3-处置修饰符值以及用户提供的*（文本）值也不区分大小写。AS3实现不得对为AS3 MDN警告描述或AS3 MDN故障描述提供的值或任何（可选）错误、警告或故障字段的值进行假设。
1. Unlike SMTP, for FTP transactions, Original-Recipient and Final Recipient SHOULD NOT be different. The value in Original-Message-ID MUST match the original Message-ID header value.
1. 与SMTP不同，对于FTP事务，原始收件人和最终收件人不应不同。原始邮件ID中的值必须与原始邮件ID标头值匹配。
2. Refer to RFC 3462 and RFC 3798 for the formatting of the Content-Type entity-headers for the MDN.
2. 有关MDN的内容类型实体头的格式，请参阅RFC 3462和RFC 3798。
3. Use an action-mode of "automatic-action" when the disposition described by the disposition type was a result of an automatic action, rather than an explicit instruction by the user for this message.
3. 当处置类型描述的处置是自动操作的结果，而不是用户对此消息的明确指示时，请使用“自动操作”的操作模式。
4. Use an action-mode of "manual-action" when the disposition described by the disposition type was a result of an explicit instruction by the user rather than some sort of automatically performed action.
4. 当处置类型描述的处置是用户明确指示的结果而不是某种自动执行的操作时，使用“手动操作”的操作模式。
5. Use a sending-mode of "MDN-sent-automatically" when the MDN is sent because the UA had previously been configured to do so.
5. 当发送MDN时，使用“MDN自动发送”的发送模式，因为UA先前已配置为这样做。
6. Use a sending-mode of "MDN-sent-manually" when the user explicitly gave permission for this particular MDN to be sent.
6. 当用户明确授予发送此特定MDN的权限时，请使用“手动发送MDN”的发送模式。
7. The sending-mode "MDN-sent-manually" is ONLY meaningful with "manual-action", not with "automatic-action".
7. 发送模式“MDN手动发送”仅对“手动操作”有意义，而对“自动操作”没有意义。
8. The "failed" disposition type MAY NOT be used for the situation in which there is some problem in processing the message other than interpreting the request for an MDN. The "processed" or other disposition type with appropriate disposition modifiers is to be used in such situations.
8. “failed”处置类型不能用于处理消息时出现问题而不是解释MDN请求的情况。在这种情况下，应使用带有适当处置修饰符的“已处理”或其他处置类型。
9. An AS3 implementation MUST present to its trading partners an FTP-compliant server interface where inbound documents and MDNs are received.
9. AS3实施必须向其贸易伙伴提供一个FTP兼容的服务器接口，以便接收入站文档和MDN。
10. An AS3 implementation MUST be able to retrieve inbound messages from its currently configured FTP server interface.
10. AS3实现必须能够从其当前配置的FTP服务器接口检索入站消息。
Note: Programming Notes 9 and 10 do not imply any specific method for supplying the FTP server interface. But, they do allow for several different types of implementations. Some vendors may choose to imbed an FTP-compliant server interface within their product, and others may choose to utilize off-the-shelf FTP servers to supply the required FTP server interface. Some may choose to utilize hosting services provided by their trading partner or by a third-party hosting service. Whichever method is utilized, an AS3 implementation MUST support rules 9 and 10.
注意：编程说明9和10并不意味着提供FTP服务器接口的任何特定方法。但是，它们允许几种不同类型的实现。一些供应商可能会选择在其产品中嵌入符合FTP的服务器接口，而其他供应商可能会选择使用现成的FTP服务器来提供所需的FTP服务器接口。有些人可能会选择利用其贸易伙伴或第三方托管服务提供的托管服务。无论使用哪种方法，AS3实现都必须支持规则9和10。
11. AS3 implementations MAY imbed an FTP server interface within their product.
11. AS3实现可能会在其产品中嵌入FTP服务器接口。
12. AS3 implementations MUST be configurable to allow the use of an external FTP hosting service.
12. AS3实现必须是可配置的，以允许使用外部FTP托管服务。
Note: An external FTP hosting service may be hosted by a third-party or possibly hosted by your trading partner.
注意：外部FTP托管服务可能由第三方托管，也可能由您的贸易伙伴托管。
13. An AS3 implementation MUST be able to send business documents and MDNs to a trading partner's currently configured FTP server interface.
13. AS3实现必须能够将业务文档和MDN发送到贸易伙伴当前配置的FTP服务器接口。
14. An AS3 implementation may imbed FTP client code into their product or use a third-party FTP client.
14. AS3实现可以将FTP客户端代码嵌入其产品中，也可以使用第三方FTP客户端。
15. Example Configurations
15. 示例配置
1. Peer to Peer Trading Partner A (TPA) is using a local FTP server, and Trading Partner B (TPB) is using an imbedded FTP server.
1. 点对点贸易伙伴A（TPA）使用本地FTP服务器，而贸易伙伴B（TPB）使用嵌入式FTP服务器。
[A Client] ----( connect )----> [B Server]
[A Client] ----( send )-------> [B Server] [AS3-Message]
[A Client] ----( disconnect )-> [B Server]
[A Client] ----( connect )----> [B Server]
[A Client] ----( send )-------> [B Server] [AS3-Message]
[A Client] ----( disconnect )-> [B Server]
[A Server] <---( connect )----- [B Client]
[A Server] <---( send )-------- [B Client] [AS3-MDN]]
[A Server] <---( disconnect )-- [B Server]
[A Client] <---( GET )--------- [A Server]
[A Server] <---( connect )----- [B Client]
[A Server] <---( send )-------- [B Client] [AS3-MDN]]
[A Server] <---( disconnect )-- [B Server]
[A Client] <---( GET )--------- [A Server]
2. Third-Party Hosting Both parties are using the same third-party-hosted FTP server.
2. 第三方托管双方使用相同的第三方托管FTP服务器。
[A Client] ----( connect )----> [Hosted Server]
[A Client] ----( send )-------> [Hosted Server] [AS3-Message]
[A Client] ----( disconnect )-> [Hosted Server]
[Hosted Server]( GET )--------> [B Client]
[A Client] ----( connect )----> [Hosted Server]
[A Client] ----( send )-------> [Hosted Server] [AS3-Message]
[A Client] ----( disconnect )-> [Hosted Server]
[Hosted Server]( GET )--------> [B Client]
[Hosted Server] <---( connect )----- [B Client]
[Hosted Server] <---( send )-------- [B Client] [AS3-MDN]]
[Hosted Server] <---( disconnect )-- [B Client]
[A Client] <---( GET )--------- [Hosted Server]
[Hosted Server] <---( connect )----- [B Client]
[Hosted Server] <---( send )-------- [B Client] [AS3-MDN]]
[Hosted Server] <---( disconnect )-- [B Client]
[A Client] <---( GET )--------- [Hosted Server]
3. Trading Partner Hosting TPA is using the imbedded FTP server hosted by TPB.
3. 托管TPA的贸易伙伴使用TPB托管的嵌入式FTP服务器。
[A Client] ----( connect )----> [B Server]
[A Client] ----( send )-------> [B Server] [AS3-Message]
[A Client] ----( disconnect )-> [B Server]
[A Client] ----( connect )----> [B Server]
[A Client] ----( send )-------> [B Server] [AS3-Message]
[A Client] ----( disconnect )-> [B Server]
[B Server] <---( connect )----- [B Client]
[B Server] <---( send )-------- [B Client] [AS3-MDN]]
[B Server] <---( disconnect )-- [B Client]
[A Client] <---( GET )--------- [B Server]
[B Server] <---( connect )----- [B Client]
[B Server] <---( send )-------- [B Client] [AS3-MDN]]
[B Server] <---( disconnect )-- [B Client]
[A Client] <---( GET )--------- [B Server]
This section will provide a brief overview of how processed, error, failure, or warning notifications are used.
本节将简要概述如何处理、错误、故障或警告通知。
When a receipt or signed receipt is requested, and the received message contents are successfully processed by the receiving EDI UA, a receipt or MDN SHOULD be returned with the "disposition-type" set to "processed". When the MDN is sent automatically by the EDI UA, and there is no explicit way for a user to control the sending of the MDN, then the first part of the "disposition-mode" should be set to "automatic-action".
当请求收据或签名收据，并且接收EDI UA成功处理了接收到的消息内容时，应返回收据或MDN，并将“处置类型”设置为“已处理”。当MDN由EDI UA自动发送，且用户没有明确的方式控制MDN的发送时，“处置模式”的第一部分应设置为“自动操作”。
When the MDN is being sent under user-configurable control, then the first part of the "disposition-mode" should be set to "manual-action". Since a request for a signed receipt should always be honored, the user MUST not be allowed to configure the UA not to send a signed receipt when the sender requests one.
当MDN在用户可配置控制下发送时，“处置模式”的第一部分应设置为“手动操作”。由于签名回执的请求应始终得到遵守，因此当发送方请求签名回执时，不得允许用户将UA配置为不发送签名回执。
The second part of the "disposition-mode" is set to "MDN-sent-manually" if the user gave explicit permission for the MDN to be sent. Again, the user MUST not be allowed to explicitly refuse to send a signed receipt when the sender requests one. The second part of the "disposition-mode" is set to "MDN-sent-automatically" whenever the EDI UA sends the MDN automatically, regardless of whether the sending was under a user's, an administrator's, or software control.
如果用户明确授予发送MDN的权限，“处置模式”的第二部分设置为“手动发送MDN”。同样，当发送者请求发送签名收据时，不得允许用户明确拒绝发送签名收据。每当EDI UA自动发送MDN时，“处置模式”的第二部分设置为“自动发送MDN”，无论发送是在用户、管理员还是软件控制下。
Since EDI content is generally handled automatically by the EDI UA, a request for a receipt or signed receipt will generally return the following in the "disposition-field":
由于EDI内容通常由EDI UA自动处理，因此收据或签名收据的请求通常会在“处置字段”中返回以下内容：
Disposition: automatic-action/MDN-sent-automatically; processed
Disposition: automatic-action/MDN-sent-automatically; processed
Note this specification does not restrict the use of the "disposition-mode" to just automatic actions. Manual actions are valid as long as it is kept in mind that a request for a signed receipt MUST be honored.
注：本规范不限制“处置模式”仅用于自动操作。只要记住必须遵守签署收据的请求，手动操作就是有效的。
The request for a signed receipt requires the use of two "disposition-notification-options", which specify the protocol format of the returned signed receipt, and the MIC algorithm used to calculate the MIC over the message contents. The "disposition-field"
签名回执请求需要使用两个“处置通知选项”，指定返回的签名回执的协议格式，以及用于计算消息内容上的MIC的MIC算法。“处置字段”
values that should be used in the case where the message content is being rejected or ignored should be specified in the MDN "disposition-field" as below. (An example of this case is when the EDI UA determines that a signed receipt cannot be returned because it does not support the requested protocol format, so the EDI UA chooses not to process the message contents itself.)
在拒绝或忽略消息内容的情况下应使用的值应在MDN“处置字段”中指定，如下所示。（这种情况的一个例子是，EDI UA确定无法返回已签名的回执，因为它不支持请求的协议格式，因此EDI UA选择不处理消息内容本身。）
Disposition: "disposition-mode"; failed/Failure: unsupported Format
Disposition: "disposition-mode"; failed/Failure: unsupported Format
The "failed" AS3-disposition-type should be used when a failure occurs that prevents the proper generation of an MDN.
当发生阻止正确生成MDN的故障时，应使用“failed”AS3处置类型。
For example, this disposition-type would apply if the sender of the message requested the application of an unsupported message-integrity-check (MIC) algorithm.
例如，如果邮件的发件人请求应用不受支持的邮件完整性检查（MIC）算法，则此处置类型将适用。
The "failure:" AS3-disposition-modifier-extension should be used with an implementation-defined description of the failure.
“failure:”AS3处置修饰符扩展应与实现定义的故障描述一起使用。
Further information about the failure may be contained in a failure-field. The syntax of the "failed" "disposition-type" is general, allowing the sending of any textual information along with the "failed" "disposition-type". Implementations WILL support any printable textual characters after the Failure disposition-type.
有关故障的更多信息可包含在故障字段中。“失败的”处置类型“的语法是通用的，允许随“失败的”处置类型一起发送任何文本信息。实现将支持故障处理类型之后的任何可打印文本字符。
For use in Internet EDI, the following "failed" values are pre-defined and MUST be supported:
对于在Internet EDI中使用，以下“失败”值是预定义的，必须支持：
"Failure: unsupported format" "Failure: unsupported MIC-algorithms"
失败：不支持的格式“”失败：不支持的MIC算法
When errors occur in processing the received message, other than content, the "disposition-field" should be set to the "processed" "disposition-type" value and the "error" "disposition-modifier" value.
当在处理收到的消息（内容除外）时出现错误，“处置字段”应设置为“已处理”“处置类型”值和“错误”“处置修饰符”值。
The "error" AS3-disposition-modifier with the "processed" disposition-type should be used to indicate that an error of some sort occurred that prevented successful processing of the message.
带有“已处理”处置类型的“error”AS3处置修饰符应用于指示发生了某种类型的错误，从而阻止了消息的成功处理。
Further information may be contained in an error-field.
更多信息可能包含在错误字段中。
An "error:" AS3-disposition-modifier-extension should be used to combine the indication of an error with a pre-defined description of a specific, well-known error. Further information about the error may be contained in an error-field.
“错误：”AS3处置修饰符扩展应用于将错误指示与特定已知错误的预定义描述相结合。有关错误的更多信息可能包含在错误字段中。
For use in Internet EDI, the following "error" "disposition-modifier" values are defined:
为了在Internet EDI中使用，定义了以下“错误”“处置修饰符”值：
"Error: decryption-failed" The receiver could not decrypt the message contents.
“错误：解密失败”接收方无法解密消息内容。
"Error: authentication-failed" The receiver could not authenticate the sender.
“错误：身份验证失败”接收方无法验证发送方。
"Error: integrity-check-failed" The receiver could not verify content integrity.
“错误：完整性检查失败”接收器无法验证内容完整性。
"Error: insufficient-message-security" The security level of the message did not match the agreed level between TPs.
“错误：消息安全性不足”消息的安全级别与TPs之间约定的级别不匹配。
"Error: decompression-failed" The receiver could not decompress the message contents.
“错误：解压缩失败”接收方无法解压缩消息内容。
"Error: unexpected-processing-error" A catch-all for any additional processing errors.
对于处理“所有意外错误”的任何其他错误：捕获所有错误。
An example of how the "disposition-field" would look when processing errors, other than content, are detected is as follows:
检测到除内容以外的处理错误时，“处置字段”的外观示例如下：
EXAMPLE Disposition: "disposition-mode"; processed/Error: decryption-failed
示例配置：“配置模式”；已处理/错误：解密失败
Situations arise in EDI where even if a trading partner cannot be authenticated correctly, the trading partners still agree to continue processing the EDI transactions. Transaction reconciliation is done between the trading partners at a later time. In the content processing warning situations described above, the "disposition-field" SHOULD be set to the "processed" "disposition-type" value, and the "warning" "disposition-modifier" value.
在电子数据交换中出现的情况是，即使贸易伙伴无法正确认证，贸易伙伴仍然同意继续处理电子数据交换交易。交易对账在交易伙伴之间稍后进行。在上述内容处理警告情况下，“处置字段”应设置为“已处理”“处置类型”值和“警告”“处置修饰符”值。
The "warning" AS3-disposition-modifier should be used with the "processed" disposition-type to indicate that the message was successfully processed but that an exceptional condition occurred.
“警告”AS3处置修饰符应与“已处理”处置类型一起使用，以指示消息已成功处理，但出现异常情况。
Further information may be contained in a warning-field.
更多信息可能包含在警告字段中。
A "warning:" AS3-disposition-modifier-extension should be used to combine the indication of a warning with an implementation-defined description of the warning. Further information about the warning may be contained in a warning-field.
“警告：”AS3处置修饰符扩展应用于将警告指示与实现定义的警告描述相结合。有关警告的更多信息可能包含在警告字段中。
For use in Internet EDI, the following "warning" "disposition-modifier" values are defined:
为了在Internet EDI中使用，定义了以下“警告”“处置修饰符”值：
"Warning: authentication-failed, processing continued"
警告：身份验证失败，处理继续
An example of how the "disposition-field" would look when processing warnings, other than content, are detected is as follows:
在处理检测到的警告（而非内容）时，“处置字段”的外观示例如下：
EXAMPLE Disposition: "disposition-mode"; processed/Warning: authentication-failed, processing continued
示例配置：“配置模式”；已处理/警告：身份验证失败，处理继续
In the near term, the exchange of public keys and certification of these keys must be handled as part of the process of establishing a trading partnership. The UA and/or EDI application interface must maintain a database of public keys used for encryption or signatures, in addition to the mapping between EDI trading partner ID and FTP URL/URI. The procedures for establishing a trading partnership and configuring the secure EDI messaging system might vary among trading partners and software packages.
在短期内，公钥的交换和这些密钥的认证必须作为建立贸易伙伴关系过程的一部分来处理。UA和/或EDI应用程序接口必须维护用于加密或签名的公钥数据库，以及EDI贸易伙伴ID和FTP URL/URI之间的映射。建立贸易伙伴关系和配置安全EDI消息传递系统的程序可能因贸易伙伴和软件包而异。
X.509 certificates are REQUIRED. It is RECOMMENDED that trading partners self-certify each other if an agreed-upon certification authority is not used. This applicability statement does NOT require the use of a certification authority.
需要X.509证书。如果未使用约定的认证机构，建议贸易伙伴相互自我认证。本适用性声明不要求使用认证机构。
The use of a certification authority is therefore OPTIONAL. Certificates may be self-signed. It is RECOMMENDED that when trading partners are using S/MIME, that they also exchange public key certificates using the recommendations specified in the S/MIME Version 3.1 Message Specification.
因此，证书颁发机构的使用是可选的。证书可以是自签名的。建议贸易伙伴在使用S/MIME时，也使用S/MIME版本3.1消息规范中指定的建议交换公钥证书。
The message formats and S/MIME conformance requirements for certificate exchange are specified in this document. In the long term, additional Internet-EDI standards may be developed to simplify the process of establishing a trading partnership, including the third-party authentication of trading partners, as well as attributes of the trading relationship.
本文档规定了证书交换的消息格式和S/MIME一致性要求。从长远来看，可能会制定额外的互联网EDI标准，以简化建立贸易伙伴关系的过程，包括贸易伙伴的第三方认证以及贸易关系的属性。
This entire document is concerned with secure transport of business-to-business data, and it considers both privacy and authentication issues.
整个文档涉及企业到企业数据的安全传输，它同时考虑了隐私和身份验证问题。
Extracted from S/MIME Version 2 Message Specification [21]:
从S/MIME版本2消息规范[21]中提取：
40-bit encryption is considered weak by most cryptographers. Using weak cryptography in S/MIME offers little actual security over sending plaintext. However, other features of S/MIME, such as the specification of tripleDES and the ability to announce stronger cryptographic capabilities to parties with whom you communicate, allow senders to create messages that use strong encryption. Using weak cryptography is never recommended unless the only alternative is no cryptography. When feasible, sending and receiving agents should inform senders and recipients the relative cryptographic strength of messages.
大多数密码学家认为40位加密很弱。在S/MIME中使用弱加密技术在发送明文时几乎没有实际的安全性。但是，S/MIME的其他功能，如三元组的规范和向与您通信的各方宣布更强加密功能的能力，允许发件人创建使用强加密的消息。除非唯一的选择是不加密，否则永远不建议使用弱加密。在可行的情况下，发送和接收代理应通知发送方和接收方消息的相对加密强度。
Extracted from S/MIME Version 3.1 Certificate Handling [11]:
摘自S/MIME版本3.1证书处理[11]：
When processing certificates, there are many situations where the processing might fail. Because the processing may be done by a user agent, a security gateway, or other program, there is no single way to handle such failures. Just because the methods to handle the failures has not been listed, however, the reader should not assume that they are not important. The opposite is true: if a certificate is not provably valid and associated with the message, the processing software should take immediate and noticeable steps to inform the end user about it.
在处理证书时，有许多情况下处理可能会失败。由于处理可能由用户代理、安全网关或其他程序完成，因此没有单一的方法来处理此类故障。然而，仅仅因为没有列出处理故障的方法，读者就不应该认为它们不重要。反之亦然：如果证书不可证明有效且与消息关联，则处理软件应立即采取明显的步骤通知最终用户。
Some of the many places where signature and certificate checking might fail include:
签名和证书检查可能失败的许多地方包括：
- no Internet mail addresses in a certificate matches the sender of a message, if the certificate contains at least one mail address - no certificate chain leads to a trusted CA - no ability to check the Certificate Revocation List (CRL) for a certificate - an invalid CRL was received - the CRL being checked is expired - the certificate is expired - the certificate has been revoked
- 如果证书至少包含一个邮件地址，则证书中没有与邮件发件人匹配的Internet邮件地址-没有证书链指向受信任的CA-无法检查证书吊销列表（CRL）对于证书-收到无效的CRL-正在检查的CRL已过期-证书已过期-证书已吊销
There are certainly other instances where a certificate may be invalid, and it is the responsibility of the processing software to check them all thoroughly, and to decide what to do if the check fails.
当然，在其他情况下，证书可能是无效的，处理软件有责任彻底检查所有证书，并决定如果检查失败怎么办。
The following certificate types MUST be supported. With URL Without URL Self Certified Certification Authority Certified
必须支持以下证书类型。有URL但没有URL自认证证书颁发机构认证
The complete certification chain MUST be included in all certificates. All certificate verifications MUST "chain to root". Additionally, the certificate hash should match the hash recomputed by the receiver.
所有证书中必须包含完整的认证链。所有证书验证必须“链到根”。此外，证书散列应与接收方重新计算的散列相匹配。
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[1] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，1996年11月。
[2] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, March 1995.
[2] Crocker，D.，“EDI对象的MIME封装”，RFC17671995年3月。
[3] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[3] Postel，J.和J.Reynolds，“文件传输协议”，标准9，RFC 959，1985年10月。
[4] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 2228, October 1997.
[4] Horowitz，M.和S.Lunt，“FTP安全扩展”，RFC2228，1997年10月。
[5] Harding, T., Drummond, R., and C. Shih, "MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet", RFC 3335, September 2002.
[5] Harding，T.，Drummond，R.，和C.Shih，“互联网上基于MIME的安全对等业务数据交换”，RFC 3335，2002年9月。
[6] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[6] Hansen，T.和G.Vaudreuil，“消息处置通知”，RFC 3798，2004年5月。
[7] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[7] Galvin，J.，Murphy，S.，Crocker，S.，和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[8] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[8] 《简单邮件传输协议》，RFC 28212001年4月。
[9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[9] Housley，R.，“加密消息语法（CMS）”，RFC3852，2004年7月。
[10] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[10] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[11] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[11] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1证书处理”，RFC 38502004年7月。
[12] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[12] Vaudreuil，G.“邮件系统管理消息报告的多部分/报告内容类型”，RFC 3462，2003年1月。
[13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[13] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[14] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", STD 11, RFC 822, August 1982.
[14] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[15] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[15] Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[16] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[16] Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[17] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[17] Gutmann，P.，“加密消息语法（CMS）的压缩数据内容类型”，RFC 3274，2002年6月。
[18] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, October 2005.
[18] Ford Hutchinson，P.，“使用TLS保护FTP”，RFC 42172005年10月。
[19] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[19] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[20] Harding, T., "Compressed Data for EDIINT", Work in Progress, January 2007.
[20] Harding，T.，“用于EDIINT的压缩数据”，正在进行的工作，2007年1月。
[21] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.
[21] Dusse，S.，Hoffman，P.，Ramsdell，B.，Lundblade，L.，和L.Repka，“S/MIME版本2消息规范”，RFC 23111998年3月。
[22] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[22] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[23] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[23] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
NOTE: All examples are provided as an illustration only, and are not considered part of the protocol specification. If an example conflicts with the protocol definitions specified above or with that of a referenced RFC, the example is wrong.
注：所有示例仅作为说明提供，不被视为协议规范的一部分。如果示例与上面指定的协议定义或参考RFC的协议定义冲突，则示例是错误的。
Date: Wed, 31 Jul 2002 13:34:50 GMT
AS3-Version: 1.0
AS3-From: cyclone
AS3-To: "trading partner"
Message-Id: <200207310834482A70BF63@host.com>
Disposition-Notification-To: ftp://host:port/mdnbox
Disposition-Notification-Options: signed-receipt-
protocol=optional,pkcs7-signature;
signed-receipt-micalg=optional,sha1
Content-Type: multipart/signed; boundary="as3BouNdary1as3";
protocol="application/pkcs7-signature"; micalg=sha1
Content-Length: 3075
Date: Wed, 31 Jul 2002 13:34:50 GMT
AS3-Version: 1.0
AS3-From: cyclone
AS3-To: "trading partner"
Message-Id: <200207310834482A70BF63@host.com>
Disposition-Notification-To: ftp://host:port/mdnbox
Disposition-Notification-Options: signed-receipt-
protocol=optional,pkcs7-signature;
signed-receipt-micalg=optional,sha1
Content-Type: multipart/signed; boundary="as3BouNdary1as3";
protocol="application/pkcs7-signature"; micalg=sha1
Content-Length: 3075
--as3BouNdary1as3
Content-Type: application/edi-x12
Content-Disposition: Attachment; filename=rfc1767.dat
--as3BouNdary1as3
Content-Type: application/edi-x12
Content-Disposition: Attachment; filename=rfc1767.dat
[ISA ...EDI transaction data...IEA...]
[ISA…EDI交易数据…IEA…]
--as3BouNdary1as3 Content-Type: application/pkcs7-signature
--as3BouNdary1as3内容类型：应用程序/pkcs7签名
[omitted binary pkcs7 signature data] --as3BouNdary1as3--
[省略的二进制pkcs7签名数据]--as3BouNdary1as3--
Date: Wed, 31 Jul 2002 13:34:50 GMT
AS3-From: "trading partner"
AS3-To: cyclone
AS3-Version: 1.0
Message-ID: <709700825.1028122454671.JavaMail@ediXchange>
Content-Type: multipart/signed; micalg=sha1;
protocol="application/pkcs7-signature";
boundary="----=_Part_57_648441049.1028122454671"
Content-Length: 1024
Date: Wed, 31 Jul 2002 13:34:50 GMT
AS3-From: "trading partner"
AS3-To: cyclone
AS3-Version: 1.0
Message-ID: <709700825.1028122454671.JavaMail@ediXchange>
Content-Type: multipart/signed; micalg=sha1;
protocol="application/pkcs7-signature";
boundary="----=_Part_57_648441049.1028122454671"
Content-Length: 1024
------=_Part_57_648441049.1028122454671
------=_Part_57_648441049.1028122454671
& Content-Type: multipart/report;
& Report-Type=disposition-notification;
& boundary="----=_Part_56_1672293592.1028122454656"
&
&------=_Part_56_1672293592.1028122454656
&Content-Type: text/plain
&Content-Transfer-Encoding: 7bit
&
&MDN for -
& Message ID: <200207310834482A70BF63@host.com>
& From: cyclone
& To: "trading partner"
& Received on: 2002-07-31 at 09:34:14 (EDT)
& Status: processed
& Comment: This is not a guarantee that the message has been
& completely processed or understood by the receiving translator
&
&------=_Part_56_1672293592.1028122454656
& Content-Type: message/disposition-notification
& Content-Transfer-Encoding: 7bit
&
& Reporting-UA: AS3 Server
& Original-Recipient: rfc822; "trading partner"
& Final-Recipient: rfc822; "trading partner"
& Original-Message-ID: <200207310834482A70BF63@host.com>
& Received-content-MIC: 7v7F++fQaNB1sVLFtMRp+dF+eG4=, sha1
& Disposition: automatic-action/MDN-sent-automatically; processed
&
&------=_Part_56_1672293592.1028122454656--
& Content-Type: multipart/report;
& Report-Type=disposition-notification;
& boundary="----=_Part_56_1672293592.1028122454656"
&
&------=_Part_56_1672293592.1028122454656
&Content-Type: text/plain
&Content-Transfer-Encoding: 7bit
&
&MDN for -
& Message ID: <200207310834482A70BF63@host.com>
& From: cyclone
& To: "trading partner"
& Received on: 2002-07-31 at 09:34:14 (EDT)
& Status: processed
& Comment: This is not a guarantee that the message has been
& completely processed or understood by the receiving translator
&
&------=_Part_56_1672293592.1028122454656
& Content-Type: message/disposition-notification
& Content-Transfer-Encoding: 7bit
&
& Reporting-UA: AS3 Server
& Original-Recipient: rfc822; "trading partner"
& Final-Recipient: rfc822; "trading partner"
& Original-Message-ID: <200207310834482A70BF63@host.com>
& Received-content-MIC: 7v7F++fQaNB1sVLFtMRp+dF+eG4=, sha1
& Disposition: automatic-action/MDN-sent-automatically; processed
&
&------=_Part_56_1672293592.1028122454656--
------=_Part_57_648441049.1028122454671
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
------=_Part_57_648441049.1028122454671
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQ
cp24hMJNbxDKHnlB9jTiQzLwSwo+/90Pc87x+Sc6EpFSUYWGAAAAAAAA
------=_Part_57_648441049.1028122454671--
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQ
cp24hMJNbxDKHnlB9jTiQzLwSwo+/90Pc87x+Sc6EpFSUYWGAAAAAAAA
------=_Part_57_648441049.1028122454671--
Notes:
笔记：
1. The lines proceeded with "&" are what the signature is calculated over.
1. 以“&”开头的行是签名的计算范围。
2. For details on how to prepare the multipart/signed with protocol="application/pkcs7-signature", see RFC 3851 [10], "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification".
2. 有关如何准备多部分/使用协议签名的详细信息=“应用程序/pkcs7签名”，请参阅RFC 3851[10]，“安全/多用途Internet邮件扩展（S/MIME）版本3.1邮件规范”。
3. Note that the textual first body part of the multipart/report can be used to include a more detailed explanation of the error conditions reported by the disposition headers. The first body part of the multipart/report, when used in this way, allows a person to better diagnose a problem in detail.
3. 请注意，multipart/report的正文第一部分可用于包含由disposition标头报告的错误条件的更详细解释。当以这种方式使用多部分/报告的第一个正文部分时，允许用户更好地详细诊断问题。
4. As specified by RFC 3462 [12], returning the original or portions of the original message in the third body part of the multipart/report is not required. This is an optional body part. However, it is RECOMMENDED that this body part be omitted or left blank.
4. 按照RFC 3462[12]的规定，不需要在多部分/报告的第三个正文部分中返回原始消息的原件或部分内容。这是可选的身体部位。但是，建议省略或留空此车身零件。
Authors' Addresses
作者地址
Terry Harding Axway 8388 E. Hartford Drive, Suite 100 Scottsdale, AZ 85255 USA
Terry Harding Axway 8388美国亚利桑那州斯科茨代尔哈特福德大道东100号套房，邮编85255
EMail: tharding@us.axway.com
EMail: tharding@us.axway.com
Richard Scott Axway 8388 E. Hartford Drive, Suite 100 Scottsdale, AZ 85255 USA
Richard Scott Axway 8388美国亚利桑那州斯科茨代尔哈特福德大道东100号套房，邮编85255
EMail: rscott@us.axway.com
EMail: rscott@us.axway.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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编辑功能的资金目前由互联网协会提供。