Network Working Group D. Moberg
Request for Comments: 4130 Cyclone Commerce
Category: Standards Track R. Drummond
Drummond Group Inc.
July 2005
Network Working Group D. Moberg
Request for Comments: 4130 Cyclone Commerce
Category: Standards Track R. Drummond
Drummond Group Inc.
July 2005
MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)
使用HTTP的基于MIME的安全对等业务数据交换，适用性声明2（AS2）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document provides an applicability statement (RFC 2026, Section 3.2) that describes how to exchange structured business data securely using the HTTP transfer protocol, instead of SMTP; the applicability statement for SMTP is found in RFC 3335. Structured business data may be XML; Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format; or other structured data formats. The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts. Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. This applicability statement is informally referred to as "AS2" because it is the second applicability statement, produced after "AS1", RFC 3335.
本文件提供了适用性声明（RFC 2026，第3.2节），描述了如何使用HTTP传输协议而不是SMTP安全地交换结构化业务数据；SMTP的适用性声明可在RFC 3335中找到。结构化业务数据可以是XML；美国国家标准委员会（ANSI）X12格式或联合国行政、商业和运输电子数据交换（UN/EDIFACT）格式的电子数据交换（EDI）；或其他结构化数据格式。数据使用标准MIME结构进行打包。身份验证和数据机密性是通过使用带有S/MIME安全主体部分的加密消息语法获得的。经过身份验证的确认使用对原始HTTP消息的多部分/签名消息处置通知（MDN）响应。本适用性声明非正式地称为“AS2”，因为它是第二份适用性声明，在RFC 3335“AS1”之后产生。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Applicable RFCs ............................................3
1.2. Terms ......................................................3
2. Overview ........................................................5
2.1. Overall Operation ..........................................5
2.2. Purpose of a Security Guideline for MIME EDI ...............5
2.3. Definitions ................................................5
2.4. Assumptions ................................................7
3. Referenced RFCs and Their Contributions .........................9
3.1. RFC 2616 HTTP v1.1 [3] .....................................9
3.2. RFC 1847 MIME Security Multiparts [6] ......................9
3.3. RFC 3462 Multipart/Report [8] .............................10
3.4. RFC 1767 EDI Content [2] ..................................10
3.5. RFC 2045, 2046, and 2049 MIME [1] .........................10
3.6. RFC 3798 Message Disposition Notification [5] .............10
3.7. RFC 3851 and 3852 S/MIME Version 3.1 Message
Specifications and Cryptographic Message Syntax (CMS) [7]..10
3.8. RFC 3023 XML Media Types [10] .............................10
4. Structure of an AS2 Message ....................................10
4.1. Introduction ..............................................10
4.2. Structure of an Internet EDI MIME Message .................11
5. HTTP Considerations ............................................12
5.1. Sending EDI in HTTP POST Requests .........................12
5.2. Unused MIME Headers and Operations ........................12
5.3. Modification of MIME or Other Headers or Parameters Used ..13
5.4. HTTP Response Status Codes ................................14
5.5. HTTP Error Recovery .......................................14
6. Additional AS2-Specific HTTP Headers ...........................14
6.1. AS2 Version Header ........................................15
6.2. AS2 System Identifiers ....................................15
7. Structure and Processing of an MDN Message .....................17
7.1. Introduction ..............................................17
7.2. Synchronous and Asynchronous MDNs .........................19
7.3. Requesting a Signed Receipt ...............................21
7.4. MDN Format and Values .....................................25
7.5. Disposition Mode, Type, and Modifier ......................30
7.6. Receipt Reply Considerations in an HTTP POST ..............35
8. Public Key Certificate Handling ................................35
9. Security Considerations ........................................36
9.1. NRR Cautions ..............................................37
9.2. HTTPS Remark ..............................................38
9.3. Replay Remark .............................................39
10. IANA Considerations ...........................................39
10.1. Registration ............................................39
11. Acknowledgements ..............................................40
12. References ....................................................40
1. Introduction ....................................................3
1.1. Applicable RFCs ............................................3
1.2. Terms ......................................................3
2. Overview ........................................................5
2.1. Overall Operation ..........................................5
2.2. Purpose of a Security Guideline for MIME EDI ...............5
2.3. Definitions ................................................5
2.4. Assumptions ................................................7
3. Referenced RFCs and Their Contributions .........................9
3.1. RFC 2616 HTTP v1.1 [3] .....................................9
3.2. RFC 1847 MIME Security Multiparts [6] ......................9
3.3. RFC 3462 Multipart/Report [8] .............................10
3.4. RFC 1767 EDI Content [2] ..................................10
3.5. RFC 2045, 2046, and 2049 MIME [1] .........................10
3.6. RFC 3798 Message Disposition Notification [5] .............10
3.7. RFC 3851 and 3852 S/MIME Version 3.1 Message
Specifications and Cryptographic Message Syntax (CMS) [7]..10
3.8. RFC 3023 XML Media Types [10] .............................10
4. Structure of an AS2 Message ....................................10
4.1. Introduction ..............................................10
4.2. Structure of an Internet EDI MIME Message .................11
5. HTTP Considerations ............................................12
5.1. Sending EDI in HTTP POST Requests .........................12
5.2. Unused MIME Headers and Operations ........................12
5.3. Modification of MIME or Other Headers or Parameters Used ..13
5.4. HTTP Response Status Codes ................................14
5.5. HTTP Error Recovery .......................................14
6. Additional AS2-Specific HTTP Headers ...........................14
6.1. AS2 Version Header ........................................15
6.2. AS2 System Identifiers ....................................15
7. Structure and Processing of an MDN Message .....................17
7.1. Introduction ..............................................17
7.2. Synchronous and Asynchronous MDNs .........................19
7.3. Requesting a Signed Receipt ...............................21
7.4. MDN Format and Values .....................................25
7.5. Disposition Mode, Type, and Modifier ......................30
7.6. Receipt Reply Considerations in an HTTP POST ..............35
8. Public Key Certificate Handling ................................35
9. Security Considerations ........................................36
9.1. NRR Cautions ..............................................37
9.2. HTTPS Remark ..............................................38
9.3. Replay Remark .............................................39
10. IANA Considerations ...........................................39
10.1. Registration ............................................39
11. Acknowledgements ..............................................40
12. References ....................................................40
12.1. Normative References ....................................40
12.2. Informative References ..................................41
Appendix A: Message Examples ......................................42
12.1. Normative References ....................................40
12.2. Informative References ..................................41
Appendix A: Message Examples ......................................42
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 [4]. This document expands on RFC 1767 to specify a comprehensive set of data security features, specifically data confidentiality, data integrity/authenticity, non-repudiation of origin, and non-repudiation of receipt over HTTP. This document also recognizes contemporary RFCs and is attempting to "re-invent" as little as possible. Although this document focuses on EDI data, any other data types describable in a MIME format are also supported.
以前关于Internet EDI的工作重点是为EDI数据指定MIME内容类型[2]，并扩展此工作以支持SMTP上的安全EC/EDI传输[4]。本文档对RFC 1767进行了扩展，以指定一套全面的数据安全功能，特别是数据机密性、数据完整性/真实性、来源的不可否认性和HTTP接收的不可否认性。本文件也承认当代RFC，并试图尽可能少地“重新发明”。尽管本文档主要关注EDI数据，但也支持以MIME格式描述的任何其他数据类型。
Internet MIME-based EDI can be accomplished by using and complying with the following RFCs:
基于Internet MIME的EDI可以通过使用并遵守以下RFC来实现：
o RFC 2616 Hyper Text Transfer Protocol o RFC 1767 EDI Content Type o RFC 3023 XML Media Types o RFC 1847 Security Multiparts for MIME o RFC 3462 Multipart/Report o RFC 2045 to 2049 MIME RFCs o RFC 3798 Message Disposition Notification o RFC 3851, 3852 S/MIME v3.1 Specification
o RFC 2616超文本传输协议o RFC 1767 EDI内容类型o RFC 3023 XML媒体类型o RFC 1847 MIME安全多部分o RFC 3462多部分/报告o RFC 2045至2049 MIME RFC o RFC 3798消息处置通知o RFC 3851、3852 S/MIME v3.1规范
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 [13].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[13]中所述进行解释。
AS2: Applicability Statement 2 (this document); see RFC 2026 [11], Section 3.2
AS2：适用性声明2（本文件）；参见RFC 2026[11]，第3.2节
EDI: Electronic Data Interchange
电子数据交换
EC: Business-to-Business Electronic Commerce
EC：企业对企业电子商务
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. This message may be either synchronous or asynchronous in nature.
接收：从接收者发送到发送者以确认收到EDI/EC交换的功能信息。此消息本质上可以是同步的，也可以是异步的。
Signed Receipt: A receipt with a digital signature.
签名收据：带有数字签名的收据。
Synchronous Receipt: A receipt returned to the sender during the same HTTP session as the sender's original message.
同步回执：在与发件人原始邮件相同的HTTP会话期间返回给发件人的回执。
Asynchronous Receipt: A receipt returned to the sender on a different communication session than the sender's original message session.
异步回执：在与发件人原始邮件会话不同的通信会话上返回给发件人的回执。
Message Disposition Notification (MDN): The Internet messaging format used to convey a receipt. This term is used interchangeably with receipt. A MDN is a receipt.
消息处置通知（MDN）：用于传递回执的Internet消息传递格式。该术语可与收据互换使用。MDN是一种收据。
Non-repudiation of receipt (NRR): A "legal event" that occurs when the original sender of an signed EDI/EC interchange has verified the signed receipt coming back from the receiver. The receipt contains data identifying the original message for which it is a receipt, including the message-ID and a cryptographic hash (MIC). The original sender must retain suitable records providing evidence concerning the message content, its message-ID, and its hash value. The original sender verifies that the retained hash value is the same as the digest of the original message, as reported in the signed receipt. NRR is not considered a technical message, but instead is thought of as an outcome of possessing relevant evidence.
收据的不可抵赖性（NRR）：当签名EDI/EC交换的原始发送方已验证从接收方返回的签名收据时发生的“法律事件”。收据包含标识其为收据的原始邮件的数据，包括邮件ID和加密哈希（MIC）。原始发件人必须保留适当的记录，提供有关邮件内容、邮件ID及其哈希值的证据。原始发件人验证保留的哈希值是否与签名回执中报告的原始邮件摘要相同。NRR不被视为技术信息，而是被视为拥有相关证据的结果。
S/MIME: A format and protocol for adding cryptographic signature and/or encryption services to Internet MIME messages.
S/MIME：用于向Internet MIME消息添加加密签名和/或加密服务的格式和协议。
Cryptographic Message Syntax (CMS): An encapsulation syntax used to digitally sign, digest, authenticate, or encrypt arbitrary messages.
加密消息语法（CMS）：用于对任意消息进行数字签名、摘要、身份验证或加密的封装语法。
SHA-1: A secure, one-way hash algorithm used in conjunction with digital signature. This is the recommended algorithm for AS2.
SHA-1：一种与数字签名结合使用的安全单向散列算法。这是AS2的推荐算法。
MD5: A secure, one-way hash algorithm used in conjunction with digital signature. This algorithm is allowed in AS2.
MD5：一种安全的单向散列算法，与数字签名结合使用。该算法在AS2中是允许的。
MIC: The message integrity check (MIC), also called the message digest, is the digest output of the hash algorithm used by the digital signature. The digital signature is computed over the MIC.
MIC：消息完整性检查（MIC），也称为消息摘要，是数字签名使用的哈希算法的摘要输出。数字签名是通过麦克风计算的。
User Agent (UA): The application that handles and processes the AS2 request.
用户代理（UA）：处理AS2请求的应用程序。
A HTTP POST operation [3] is used to send appropriately packaged EDI, XML, or other business data. The Request-URI ([3], Section 9.5) identifies a process for unpacking and handling the message data and for generating a reply for the client that contains a message disposition acknowledgement (MDN), either signed or unsigned. The MDN is either returned in the HTTP response message body or by a new HTTP POST operation to a URL for the original sender.
HTTP POST操作[3]用于发送适当打包的EDI、XML或其他业务数据。请求URI（[3]，第9.5节）标识了一个用于解包和处理消息数据的过程，以及用于为包含消息处置确认（MDN）的客户端生成应答的过程，该应答可以是已签名的，也可以是未签名的。MDN要么在HTTP响应消息正文中返回，要么通过新的HTTP POST操作返回到原始发件人的URL。
This request/reply transactional interchange can provide secure, reliable, and authenticated transport for EDI or other business data using HTTP as a transfer protocol.
这种请求/应答事务交换可以使用HTTP作为传输协议，为EDI或其他业务数据提供安全、可靠和经过身份验证的传输。
The security protocols and structures used also support auditable records of these document data transmissions, acknowledgements, and authentication.
使用的安全协议和结构还支持这些文档数据传输、确认和身份验证的可审核记录。
The purpose of these specifications is to ensure interoperability between B2B EC user agents, invoking some or all of the commonly expected security features. This document is also NOT limited to strict EDI use; it applies to any electronic commerce application for which business data needs to be exchanged over the Internet in a secure manner.
这些规范的目的是确保B2B EC用户代理之间的互操作性，调用一些或所有常见的预期安全特性。本文件也不限于严格的EDI使用；它适用于任何需要在互联网上以安全方式交换业务数据的电子商务应用程序。
This document's focus is on the formats and protocols for exchanging EDI/EC content securely in the Internet's HTTP environment.
本文档的重点是在Internet的HTTP环境中安全交换EDI/EC内容的格式和协议。
In the "secure transmission loop" for EDI/EC, one organization sends a signed and encrypted EDI/EC interchange to another organization and
在EDI/EC的“安全传输环路”中，一个组织向另一个组织发送经过签名和加密的EDI/EC交换，并
requests a signed receipt, and later the receiving organization sends this signed receipt back to the sending organization. In other words, the following transpires:
请求签名收据，然后接收组织将此签名收据发送回发送组织。换言之，发生了以下情况：
o The organization sending EDI/EC data signs and encrypts the data using S/MIME. In addition, the message will request that a signed receipt be returned to the sender. To support NRR, the original sender retains records of the message, message-ID, and digest (MIC) value.
o 发送EDI/EC数据的组织使用S/MIME对数据进行签名和加密。此外，该消息将请求将已签名的回执返回给发件人。为了支持NRR，原始发件人保留消息、消息ID和摘要（MIC）值的记录。
o The receiving organization decrypts the message and verifies the signature, resulting in verified integrity of the data and authenticity of the sender.
o 接收组织解密消息并验证签名，从而验证数据的完整性和发送方的真实性。
o The receiving organization then returns a signed receipt using the HTTP reply body or a separate HTTP POST operation to the sending organization in the form of a signed message disposition notification. This signed receipt will contain the hash of the received message, allowing the original sender to have evidence that the received message was authenticated and/or decrypted properly by the receiver.
o 然后，接收组织使用HTTP回复正文或单独的HTTP POST操作以签名消息处置通知的形式将签名回执返回给发送组织。此签名回执将包含接收到的消息的散列，允许原始发送方有证据证明接收到的消息已由接收方正确验证和/或解密。
The above describes functionality that, if implemented, will satisfy all security requirements and implement non-repudiation of receipt for the exchange. This specification, however, leaves full flexibility for users to decide the degree to which they want to deploy those security features with their trading partners.
上述描述的功能，如果实现，将满足所有安全要求，并实现交易所的不可否认性。然而，该规范为用户提供了充分的灵活性，以决定他们希望与贸易伙伴一起部署这些安全功能的程度。
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 first term is used if the acknowledgment is for an interchange resulting in a receipt that is NOT signed. The second term is used if the acknowledgement is for an interchange resulting in a receipt that IS signed.
用于确认EDI/EC交换交付的功能活动和信息的术语为“收据”或“签名收据”。如果确认用于交换，导致未签名的收据，则使用第一个术语。第二个术语用于确认交换，从而产生已签名的收据。
The term non-repudiation of receipt (NRR) is often used in combination with receipts. NRR refers to a legal event that occurs only when the original sender of an interchange has verified the signed receipt coming back from recipient of the message, and has verified that the returned MIC value inside the MDN matches the previously recorded value for the original message.
收据的不可抵赖性（NRR）一词通常与收据结合使用。NRR是指仅当交换的原始发送方验证了从消息接收方返回的签名回执，并且验证了MDN内返回的MIC值与原始消息先前记录的值匹配时才会发生的法律事件。
NRR is best established when both the original message and the receipt make use of digital signatures. See the Security Considerations section for some cautions regarding NRR.
当原始邮件和回执都使用数字签名时，NRR的建立效果最佳。有关NRR的一些注意事项，请参见安全注意事项部分。
For information on how to format and process receipts in AS2, refer to Section 7.
有关如何在AS2中格式化和处理收据的信息，请参阅第7节。
o Encrypted object is an EDI/EC Interchange.
o 加密对象是EDI/EC交换。
This specification assumes that a typical EDI/EC interchange is the lowest-level object that will be subject to security services.
本规范假设典型的EDI/EC交换是受安全服务约束的最低级别对象。
Specifically, in EDI ANSI X12, this means that anything between and including, segments ISA and IEA is secured. In EDIFACT, this means that anything between, and including, segments UNA/UNB and UNZ is secured. In other words, the EDI/EC interchanges including envelope segments remain intact and unreadable during fully secured transport.
具体而言，在EDI ANSI X12中，这意味着ISA段和IEA段之间的任何内容都是安全的。实际上，这意味着UNA/UNB段和UNZ段之间的任何内容都是安全的。换言之，在完全安全的运输过程中，EDI/EC交换（包括信封段）保持完整且无法读取。
o EDI envelope headers are encrypted.
o EDI信封头是加密的。
Congruent with the above statement, EDI envelope headers are NOT visible in the MIME package.
与上述语句一致，EDI信封头在MIME包中不可见。
In order to optimize routing from existing commercial EDI networks (called Value Added Networks or VANs) to the Internet, it would be useful to make some envelope information visible. This specification, however, provides no support for this optimization.
为了优化从现有商业EDI网络（称为增值网络或VAN）到Internet的路由，使一些信封信息可见将是有用的。但是，本规范不支持此优化。
o X12.58 and UN/EDIFACT Security Considerations
o 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提供安全性。本规范不规定使用或不使用这些安全标准。它们都与本规范完全兼容，尽管可能是冗余的。
o Encrypted or Unencrypted Data
o 加密或未加密数据
This specification allows for EDI/EC message exchange in which the EDI/EC data can be either unprotected or protected by means of encryption.
本规范允许EDI/EC消息交换，其中EDI/EC数据可以不受保护，也可以通过加密方式进行保护。
o Signed or Unsigned Data
o 有符号或无符号数据
This specification allows for EDI/EC message exchange with or without digital signature of the original EDI transmission.
本规范允许使用或不使用原始EDI传输的数字签名进行EDI/EC消息交换。
o Optional Use of Receipt
o 收据的可选使用
This specification allows for EDI/EC message transmission with or without a request for receipt notification. A signed receipt notification is requested; however, a MIC value is REQUIRED as part of the returned receipt, except when a severe error condition prevents computation of the digest value. In the exceptional case, a signed receipt should be returned with an error message that effectively explains why the MIC is absent.
本规范允许EDI/EC消息传输，无论是否要求接收通知。要求签署接收通知；然而，MIC值作为返回收据的一部分是必需的，除非严重错误情况阻止了摘要值的计算。在例外情况下，签名收据应返回一条错误消息，有效解释MIC缺席的原因。
o Use of Synchronous or Asynchronous Receipts
o 使用同步或异步接收
In addition to a receipt request, this specification allows the specification of the type of receipt that should be returned. It supports synchronous or asynchronous receipts in the MDN format specified in Section 7 of this document.
除了收据请求外，此规范还允许指定应返回的收据类型。它支持本文档第7节中指定的MDN格式的同步或异步接收。
o Security Formatting
o 安全格式
This specification relies on the guidelines set forth in RFC 3851/3852 [7] "S/MIME Version 3.1 Message Specification; Cryptographic Message Syntax".
本规范依赖于RFC 3851/3852[7]“S/MIME版本3.1消息规范；加密消息语法”中规定的指南。
o Hash Function, Message Digest Choices
o 哈希函数，消息摘要选项
When a signature is used, it is RECOMMENDED that the SHA-1 hash algorithm be used for all outgoing messages, and that both MD5 and SHA-1 be supported for incoming messages.
使用签名时，建议对所有传出消息使用SHA-1哈希算法，并且对传入消息同时支持MD5和SHA-1。
o Permutation Summary
o 排列摘要
In summary, the following twelve security permutations are possible in any given trading relationship:
总之，在任何给定的交易关系中，以下十二种证券排列是可能的：
1. Sender sends un-encrypted data and does NOT request a receipt.
1. 发件人发送未加密的数据，不请求收据。
2. Sender sends un-encrypted data and requests an unsigned receipt. Receiver sends back the unsigned receipt.
2. 发送方发送未加密的数据并请求未签名的收据。接收方发回未签字的收据。
3. Sender sends un-encrypted data and requests a signed receipt. Receiver sends back the signed receipt.
3. 发送方发送未加密的数据并请求签名收据。接收方发回已签名的收据。
4. Sender sends encrypted data and does NOT request a receipt.
4. 发送方发送加密数据，不请求收据。
5. Sender sends encrypted data and requests an unsigned receipt. Receiver sends back the unsigned receipt.
5. 发送方发送加密数据并请求未签名的收据。接收方发回未签字的收据。
6. Sender sends encrypted data and requests a signed receipt. Receiver sends back the signed receipt.
6. 发送方发送加密数据并请求签名收据。接收方发回已签名的收据。
7. Sender sends signed data and does NOT request a signed or unsigned receipt.
7. 发送方发送已签名的数据，不请求已签名或未签名的回执。
8. Sender sends signed data and requests an unsigned receipt. Receiver sends back the unsigned receipt.
8. 发送方发送已签名的数据并请求未签名的收据。接收方发回未签字的收据。
9. Sender sends signed data and requests a signed receipt. Receiver sends back the signed receipt.
9. 发送方发送签名数据并请求签名收据。接收方发回已签名的收据。
10. Sender sends encrypted and signed data and does NOT request a signed or unsigned receipt.
10. 发送方发送加密和签名的数据，不请求签名或未签名的收据。
11. Sender sends encrypted and signed data and requests an unsigned receipt. Receiver sends back the unsigned receipt.
11. 发送方发送加密和签名的数据，并请求未签名的收据。接收方发回未签字的收据。
12. Sender sends encrypted and signed data and requests a signed receipt. Receiver sends back the signed receipt.
12. 发送方发送加密和签名数据，并请求签名收据。接收方发回已签名的收据。
Users can choose any of the twelve possibilities, but only the last example (12), when a signed receipt is requested, offers the whole suite of security features described in Section 2.3.1, "The Secure Transmission Loop".
用户可以选择十二种可能性中的任何一种，但只有最后一个示例（12）在请求签名收据时提供了第2.3.1节“安全传输环路”中所述的整套安全功能。
Additionally, the receipts discussed above may be either synchronous or asynchronous depending on the type requested. The use of either the synchronous or asynchronous receipts does not change the nature of the secure transmission loop in support of NRR.
此外，根据请求的类型，上面讨论的收据可以是同步的，也可以是异步的。同步或异步接收的使用不会改变支持NRR的安全传输环路的性质。
This document specifies how data is transferred using HTTP.
本文档指定如何使用HTTP传输数据。
This document defines security multipart for MIME: multipart/encrypted and multipart/signed.
本文档为MIME定义了安全多部分：多部分/加密和多部分/签名。
This RFC defines the use of the multipart/report content type, something that the MDN RFC 3798 builds upon.
此RFC定义了多部分/报表内容类型的使用，MDN 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 an MDN is requested, and the format and syntax of the MDN. The MDN is the basis upon which receipts and signed receipts are defined in this specification.
此Internet RFC定义了如何请求MDN，以及MDN的格式和语法。MDN是本规范中定义收据和签名收据的基础。
3.7. RFC 3851 and 3852 S/MIME Version 3.1 Message Specifications and Cryptographic Message Syntax (CMS) [7]
3.7. RFC 3851和3852 S/MIME版本3.1消息规范和加密消息语法（CMS）[7]
This specification describes how S/MIME will carry CMS Objects.
本规范描述了S/MIME如何携带CMS对象。
This RFC defines the use of content type "application" for XML (application/xml).
此RFC定义了XML（application/XML）的内容类型“application”的使用。
The basic structure of an AS2 message consists of MIME format inside an HTTP message with a few additional specific AS2 headers. The structures below are described hierarchically in terms of which RFCs are applied to form the specific structure. For details of how to code in compliance with all RFCs involved, turn directly to the RFCs referenced. Any difference between AS2 implantations and RFCs are mentioned specifically in the sections below.
AS2消息的基本结构由HTTP消息中的MIME格式和一些附加的特定AS2头组成。下面的结构按照应用RFC以形成特定结构的方式进行分层描述。有关如何按照所有涉及的RFC编码的详细信息，请直接转到参考的RFC。AS2植入和RFC之间的任何差异在下面的章节中特别提到。
No encryption, no signature
-RFC2616/2045
-RFC1767/RFC3023 (application/EDIxxxx or /xml)
No encryption, no signature
-RFC2616/2045
-RFC1767/RFC3023 (application/EDIxxxx or /xml)
No encryption, signature
-RFC2616/2045
-RFC1847 (multipart/signed)
-RFC1767/RFC3023 (application/EDIxxxx or /xml)
-RFC3851 (application/pkcs7-signature)
No encryption, signature
-RFC2616/2045
-RFC1847 (multipart/signed)
-RFC1767/RFC3023 (application/EDIxxxx or /xml)
-RFC3851 (application/pkcs7-signature)
Encryption, no signature
-RFC2616/2045
-RFC3851 (application/pkcs7-mime)
-RFC1767/RFC3023 (application/EDIxxxx or /xml)(encrypted)
Encryption, no signature
-RFC2616/2045
-RFC3851 (application/pkcs7-mime)
-RFC1767/RFC3023 (application/EDIxxxx or /xml)(encrypted)
Encryption, signature
-RFC2616/2045
-RFC3851 (application/pkcs7-mime)
-RFC1847 (multipart/signed)(encrypted)
-RFC1767/RFC3023 (application/EDIxxxx or /xml)(encrypted)
-RFC3851 (application/pkcs7-signature)(encrypted)
Encryption, signature
-RFC2616/2045
-RFC3851 (application/pkcs7-mime)
-RFC1847 (multipart/signed)(encrypted)
-RFC1767/RFC3023 (application/EDIxxxx or /xml)(encrypted)
-RFC3851 (application/pkcs7-signature)(encrypted)
MDN over HTTP, no signature -RFC2616/2045 -RFC3798 (message/disposition-notification)
HTTP上的MDN，无签名-RFC2616/2045-RFC3798（消息/处置通知）
MDN over HTTP, signature
-RFC2616/2045
-RFC1847 (multipart/signed)
-RFC3798 (message/disposition-notification)
-RFC3851 (application/pkcs7-signature)
MDN over HTTP, signature
-RFC2616/2045
-RFC1847 (multipart/signed)
-RFC3798 (message/disposition-notification)
-RFC3851 (application/pkcs7-signature)
MDN over SMTP, no signature MDN over SMTP, signature Refer to the EDI over SMTP standard [4].
MDN over SMTP，无签名MDN over SMTP，签名参考EDI over SMTP标准[4]。
Although 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: 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: application/EDIFACT
Content-Type: application/edi-consent
Content-Type: application/XML
The request line will have the form: "POST Request-URI HTTP/1.1", with spaces and followed by a CRLF. The Request URI is typically exchanged out of band, as part of setting up a bilateral trading partner agreement. Applications SHOULD be prepared to deal with an initial reply containing a status indicating a need for authentication of the usual types used for authorizing access to the Request-URI ([3], Section 10.4.2 and elsewhere).
请求行的格式为：“POST请求URI HTTP/1.1”，带有空格，后跟CRLF。请求URI通常在带外交换，作为建立双边贸易伙伴协议的一部分。应用程序应准备好处理初始回复，该回复包含一个状态，该状态指示需要验证用于授权访问请求URI的常用类型（[3]，第10.4.2节和其他地方）。
The request line is followed by entity headers specifying content length ([3], Section 14.14) and content type ([3], Section 14.18). The Host request header ([3], Sections 9 and 14.23) is also included.
请求行后面是实体头，指定内容长度（[3]，第14.14节）和内容类型（[3]，第14.18节）。还包括主机请求头（[3]，第9节和第14.23节）。
When using Transport Layer Security [15] or SSLv3, the request-URI SHOULD indicate the appropriate scheme value, HTTPS. Usually only a multipart/signed message body would be sent using TLS, as encrypted message bodies would be redundant. However, encrypted message bodies are not prohibited.
当使用传输层安全[15]或SSLv3时，请求URI应指示适当的方案值HTTPS。通常使用TLS只发送多部分/签名的消息体，因为加密的消息体是冗余的。但是，加密邮件正文并不禁止。
The receiving AS2 system MAY disconnect from the sending AS2 system before completing the reception of the entire entity if it determines that the entity being sent is too large to process.
如果接收AS2系统确定被发送的实体太大而无法处理，则在完成整个实体的接收之前，接收AS2系统可能会断开与发送AS2系统的连接。
For HTTP version 1.1, TCP persistent connections are the default, ([3] Sections 8.1.2, 8.2, and 19.7.1). A number of other differences exist because HTTP does not conform to MIME [1] as used in SMTP transport. Relevant differences are summarized below.
对于HTTP版本1.1，TCP持久连接是默认连接（第8.1.2、8.2和19.7.1节）。由于HTTP不符合SMTP传输中使用的MIME[1]，因此存在许多其他差异。相关差异总结如下。
HTTP can handle binary data and so there is no need to use the content transfer encodings of MIME [1]. This difference is discussed in [3], Section 19.4.5. However, a content transfer encoding value of binary or 8-bit is permissible but not required. The absence of this header MUST NOT result in transaction failure. Content transfer encoding of MIME bodyparts within the AS2 message body is also allowed.
HTTP可以处理二进制数据，因此不需要使用MIME[1]的内容传输编码。[3]第19.4.5节讨论了这种差异。但是，允许但不需要二进制或8位的内容传输编码值。缺少此标头不得导致事务失败。还允许对AS2消息体中的MIME bodyparts进行内容传输编码。
In [3], Section 3.7.2, it is explicitly noted that multiparts MUST have null epilogues.
在[3]第3.7.2节中，明确指出多部分必须有空尾声。
In [4], Section 5.4.1, options for large file processing are discussed for SMTP transport. For HTTP, large files SHOULD be handled correctly by the TCP layer. However, in [3], Sections 3.5 and 3.6 discuss some options for compressing or chunking entities to be transferred. In [3], Section 8.1.2.2 discusses a pipelining option that is useful for segmenting large amounts of data.
在[4]第5.4.1节中，讨论了SMTP传输的大文件处理选项。对于HTTP，大型文件应该由TCP层正确处理。然而，在[3]中，第3.5节和第3.6节讨论了压缩或分块要传输的实体的一些选项。在[3]中，第8.1.2.2节讨论了用于分割大量数据的管道选项。
The use of the content-length header MUST follow the guidelines of [3], specifically Sections 4.4 and 14.13.
内容长度标题的使用必须遵循[3]的指导原则，特别是第4.4节和第14.13节。
The final and original recipient values SHOULD be the same value. These values MUST NOT be aliases or mailing lists.
最终收件人值和原始收件人值应相同。这些值不能是别名或邮件列表。
Message-Id and Original-Message-Id is formatted as defined in RFC 2822 [9]:
消息Id和原始消息Id的格式如RFC 2822[9]中所定义：
"<" id-left "@" id-right ">" (RFC 2822, 3.6.4)
"<" id-left "@" id-right ">" (RFC 2822, 3.6.4)
Message-Id length is a maximum of 998 characters. For maximum backward compatibility, Message-Id length SHOULD be 255 characters or less. Message-Id SHOULD be globally unique, and id-right SHOULD be something unique to the sending host environment (e.g., a host name).
消息Id长度最多为998个字符。为了实现最大的向后兼容性，消息Id长度应不超过255个字符。消息Id应该是全局唯一的，Id right应该是发送主机环境唯一的内容（例如，主机名）。
When sending a message, always include the angle brackets. Angle brackets are not part of the Message-Id value. For maximum backward compatibility, when receiving a message, do not check for angle brackets. When creating the Original-Message-Id header in an MDN, always use the exact syntax as received on the original message; don't strip or add angle brackets.
发送消息时，请始终使用尖括号。尖括号不是消息Id值的一部分。为了获得最大的向后兼容性，在接收消息时，不要检查尖括号。在MDN中创建原始消息Id头时，始终使用原始消息上收到的确切语法；不要去掉或添加尖括号。
The host request header field MUST be included in the POST request made when sending business data. This field is intended to allow one server IP address to service multiple hostnames, and potentially to conserve IP addresses. See [3], Sections 14.23 and 19.5.1.
主机请求头字段必须包含在发送业务数据时发出的POST请求中。此字段旨在允许一个服务器IP地址为多个主机名提供服务，并可能保留IP地址。见[3]，第14.23节和第19.5.1节。
The status codes return status concerning HTTP operations. For example, the status code 401, together with the WWW-Authenticate header, is used to challenge the client to repeat the request with an Authorization header. Other explicit status codes are documented in [3], Section 6.1.1 and throughout Section 10.
状态代码返回有关HTTP操作的状态。例如，状态代码401与WWW-Authenticate报头一起用于质询客户机使用授权报头重复请求。其他明确的状态代码记录在[3]第6.1.1节和整个第10节中。
For errors in the request-URI, 400 ("Bad Request"), 404 ("Not Found"), and similar codes are appropriate status codes. These codes and their semantics are specified by [3]. A careful examination of these codes and their semantics should be made before implementing any retry functionality. Retries SHOULD NOT be made if the error is not transient or if retries are explicitly discouraged.
对于请求URI中的错误，400（“错误请求”）、404（“未找到”）和类似代码是合适的状态代码。这些代码及其语义由[3]指定。在实现任何重试功能之前，应仔细检查这些代码及其语义。如果错误不是暂时性的或明确不鼓励重试，则不应重试。
If the HTTP client fails to read the HTTP server response data, the POST operation with identical content, including same Message-ID, SHOULD be repeated, if the condition is transient.
如果HTTP客户端无法读取HTTP服务器响应数据，则如果情况是暂时的，则应重复具有相同内容（包括相同消息ID）的POST操作。
The Message-ID on a POST operation can be reused if and only if all of the content (including the original Date) is identical.
当且仅当所有内容（包括原始日期）相同时，POST操作上的消息ID才能重用。
Details of the retry process (including time intervals to pause, number of retries to attempt, and timeouts for retrying) are implementation dependent. These settings are selected as part of the trading partner agreement.
重试过程的详细信息（包括暂停的时间间隔、重试次数和重试超时）取决于实现。这些设置作为贸易伙伴协议的一部分进行选择。
Servers SHOULD be prepared to receive a POST with a repeated Message-ID. The MIME reply body previously sent SHOULD be resent, including the MDN and other MIME parts.
服务器应准备好接收具有重复消息ID的帖子。应重新发送之前发送的MIME回复正文，包括MDN和其他MIME部分。
The following headers are to be included in all AS2 messages and all AS2 MDNs, except for asynchronous MDNs that are sent using SMTP and that follow the AS1 semantics[4].
以下标头将包含在所有AS2邮件和所有AS2 MDN中，但使用SMTP发送并遵循AS1语义的异步MDN除外[4]。
To promote backward compatibility, AS2 includes a version header:
为了提高向后兼容性，AS2包含一个版本头：
AS2-Version: 1.0 - Used in all implementations of this specification. 1.x will be interpreted as 1.0 by all implementations with the "AS2 Version: 1.0" header. That is, only the most significant digit is used as the version identifier for those not implementing additional non-AS2-specified functionality. "AS2-Version: 1.0 through 1.9" MAY be used. All implementations MUST interpret "1.0 through 1.9" as implementing this specification. However, an implementation MAY extend this specification with additional functionality by specifying versions 1.1 through 1.9. If this mechanism is used, the additional functionality MUST be completely transparent to implementations with the "AS2-Version: 1.0" designation.
AS2版本：1.0-用于本规范的所有实现。所有带有“AS2版本：1.0”标题的实现都会将1.x解释为1.0。也就是说，对于那些没有实现其他非AS2指定功能的用户，只有最高有效位被用作版本标识符。可使用“AS2版本：1.0至1.9”。所有实现都必须将“1.0到1.9”解释为实现本规范。但是，一个实现可以通过指定版本1.1到1.9来扩展本规范的附加功能。如果使用此机制，附加功能必须对具有“AS2版本：1.0”名称的实现完全透明。
AS2-Version: 1.1 - Designates those implementations that support compression as defined by RFC 3274.
AS2版本：1.1-指定那些支持RFC 3274定义的压缩的实现。
Receiving systems MUST NOT fail due to the absence of the AS2-Version header. Its absence would indicate that the message is from an implementation based on a previous version of this specification.
接收系统不得因缺少AS2版本标头而出现故障。如果没有，则表示该消息来自基于本规范以前版本的实现。
To aid the receiving system in identifying the sending system, AS2-From and AS2-To headers are used.
为了帮助接收系统识别发送系统，使用AS2 From和AS2 To报头。
AS2-From: < AS2-name >
AS2-To: < AS2-name >
AS2-From: < AS2-name >
AS2-To: < AS2-name >
These AS2 headers contain textual values, as described below, identifying the sender/receiver of a data exchange. Their values may be company specific, such as Data Universal Numbering System (DUNS) numbers, or they may be simply identification strings agreed upon between the trading partners.
这些AS2标头包含文本值，如下所述，用于标识数据交换的发送方/接收方。它们的值可能是特定于公司的，例如数据通用编号系统（DUNS）编号，也可能只是贸易伙伴之间商定的标识字符串。
AS2-text = "!" / ; printable ASCII characters
%d35-91 / ; except double-quote (%d34)
%d93-126 ; or backslash (%d92)
AS2-text = "!" / ; printable ASCII characters
%d35-91 / ; except double-quote (%d34)
%d93-126 ; or backslash (%d92)
AS2-qtext = AS2-text / SP ; allow space only in quoted text
AS2-qtext = AS2-text / SP ; allow space only in quoted text
AS2-quoted-pair = "\" DQUOTE / ; \" or
"\" "\" ; \\
AS2-quoted-pair = "\" DQUOTE / ; \" or
"\" "\" ; \\
AS2-quoted-name = DQUOTE 1*128( AS2-qtext /
AS2-quoted-pair) DQUOTE
AS2-quoted-name = DQUOTE 1*128( AS2-qtext /
AS2-quoted-pair) DQUOTE
AS2-atomic-name = 1*128AS2-text
AS2-atomic-name = 1*128AS2-text
AS2-name = AS2-atomic-name / AS2-quoted-name
AS2-name = AS2-atomic-name / AS2-quoted-name
The AS2-From header value and the AS2-To header value MUST each be an AS2-name, MUST each be comprised of from 1 to 128 printable ASCII characters, and MUST NOT be folded. The value in each of these headers is case-sensitive. The string definitions given above are in ABNF format [14].
AS2 From标头值和AS2 To标头值必须分别为AS2名称，必须由1到128个可打印ASCII字符组成，并且不得折叠。每个标头中的值都区分大小写。上面给出的字符串定义采用ABNF格式[14]。
The AS2-quoted-name SHOULD be used only if the AS2-name does not conform to AS2-atomic-name.
仅当AS2名称与AS2原子名称不一致时，才应使用AS2引用名称。
The AS2-To and AS2-From header fields MUST be present in all AS2 messages and AS2 MDNs whether asynchronous or synchronous in nature, except for asynchronous MDNs, which are sent using SMTP.
AS2 To和AS2 From标头字段必须存在于所有AS2邮件和AS2 MDN中，无论是异步还是同步性质，但使用SMTP发送的异步MDN除外。
The AS2-name for the AS2-To header in a response or MDN MUST match the AS2-name of the AS2-From header in the corresponding request message. Likewise, the AS2-name for the AS2-From header in a response or MDN MUST match the AS2-name of the AS2-To header in the corresponding AS2 request message.
响应或MDN中AS2 To头的AS2名称必须与相应请求消息中AS2 From头的AS2名称匹配。同样，响应或MDN中AS2 From头的AS2名称必须与相应AS2请求消息中AS2 To头的AS2名称匹配。
The sending system may choose to limit the possible AS2-To/AS2-From textual values but MUST not exceed them. The receiving system MUST make no restrictions on the textual values and SHOULD handle all possible implementations. However, implementers must be aware that older AS2 products may not adhere to this convention. Trading partner agreements should be made to ensure that older products can support the system identifiers that are used.
发送系统可以选择从文本值限制可能的AS2到/AS2，但不得超过它们。接收系统必须不限制文本值，并应处理所有可能的实现。但是，实施者必须意识到，较旧的AS2产品可能不符合此约定。应签订贸易伙伴协议，以确保旧产品能够支持所使用的系统标识符。
There is no required response to a client request containing invalid or unknown AS2-From or AS2-To header values. The receiving AS2 system MAY return an unsigned MDN with an explanation of the error, if the sending system requested an MDN.
对于包含无效或未知AS2 From或AS2 to标头值的客户端请求，没有必需的响应。如果发送系统请求MDN，则接收AS2系统可能返回一个未签名的MDN并解释错误。
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. 能够将签署的收据返回给发送交易伙伴。
5. The ability to return either a synchronous or an asynchronous receipt as the sending party requests.
5. 能够根据发送方的请求返回同步或异步回执。
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, 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. The authentication algorithm performs the following:
3. 接收交易伙伴使用发送方的公钥对消息中的签名进行身份验证。身份验证算法执行以下操作：
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:
7. 多部分/签名消息的第二部分包含数字签名。multipart/signed协议第二部分中指定的“协议”选项如下：
S/MIME: protocol = "application/pkcs-7-signature"
S/MIME: protocol = "application/pkcs-7-signature"
8. The signature information is formatted according to S/MIME specifications.
8. 签名信息根据S/MIME规范格式化。
The EC Interchange and the RFC 1767 MIME EDI content header can actually be part of a multi-part MIME content-type. When the EDI Interchange is part of a multi-part MIME content-type, the MIC MUST be calculated across the entire multi-part content, including the MIME headers.
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 as follows:
当EDI交换的发送方收到签名的MDN时，发送方可按如下方式使用：
o As an acknowledgement that the EDI Interchange sent was delivered and acknowledged by the receiving trading partner. The receiver does this by returning the original-message-id of the sent message in the MDN portion of the signed receipt.
o 作为对发送的EDI交换已交付的确认，并由接收交易伙伴确认。接收方通过在签名收据的MDN部分中返回已发送消息的原始消息id来完成此操作。
o As an acknowledgement 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.
o 作为接收交易伙伴验证EDI交换完整性的确认。接收机通过在签名MDN的“received content MIC”字段中返回已接收EC交换（和1767 MIME头）的计算MIC来实现这一点。
o As an acknowledgement that the receiving trading partner has authenticated the sender of the EDI Interchange.
o 作为接收交易伙伴已认证EDI交换发送方的确认。
o 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.
o 当发送方使用接收交易伙伴的公钥成功验证已签名的MDN，并且MDN内返回的MIC值与原始消息摘要相同时，作为不可否认的接收。
The AS2-MDN exists in two varieties: synchronous and asynchronous.
AS2-MDN有两种类型：同步和异步。
The synchronous AS2-MDN is sent as an HTTP response to an HTTP POST or as an HTTPS response to an HTTPS POST. This form of AS2-MDN is called synchronous because the AS2-MDN is returned to the originator of the POST on the same TCP/IP connection.
同步AS2-MDN作为HTTP POST的HTTP响应或HTTPS POST的HTTPS响应发送。这种形式的AS2-MDN称为同步，因为AS2-MDN在同一TCP/IP连接上返回给POST的发起人。
The asynchronous AS2-MDN is sent on a separate HTTP, HTTPS, or SMTP TCP/IP connection. Logically, the asynchronous AS2-MDN is a response to an AS2 message. However, at the transfer-protocol layer, assuming that no HTTP pipelining is utilized, the asynchronous AS2-MDN is delivered on a unique TCP/IP connection, distinct from that used to deliver the original AS2 message. When handling an asynchronous request, the HTTP response MUST be sent back before the MDN is processed and sent on the separate connection.
异步AS2-MDN通过单独的HTTP、HTTPS或SMTP TCP/IP连接发送。从逻辑上讲，异步AS2-MDN是对AS2消息的响应。然而，在传输协议层，假设没有使用HTTP管道，异步AS2-MDN是在唯一的TCP/IP连接上交付的，与用于交付原始AS2消息的连接不同。在处理异步请求时，在处理MDN并在单独的连接上发送之前，必须先发回HTTP响应。
When an asynchronous AS2-MDN is requested by the sender of an AS2 message, the synchronous HTTP or HTTPS response returned to the sender prior to terminating the connection MUST be a transfer-layer response indicating the success or failure of the data transfer. The format of such a synchronous response MAY be the same as that response returned when no AS2-MDN is requested.
当AS2消息的发送方请求异步AS2-MDN时，在终止连接之前返回给发送方的同步HTTP或HTTPS响应必须是表示数据传输成功或失败的传输层响应。这种同步响应的格式可能与未请求AS2-MDN时返回的响应相同。
The following diagram illustrates the synchronous versus asynchronous varieties of AS2-MDN delivery using HTTP:
下图说明了使用HTTP的AS2-MDN交付的同步与异步类型：
Synchronous AS2-MDN
同步AS2-MDN
[Peer1] ----( connect )----> [Peer2]
[Peer1] -----( send )------> [Peer2] [HTTP Request [AS2-Message]]
[Peer1] <---( receive )----- [Peer2] [HTTP Response [AS2-MDN]]
[Peer1] ----( connect )----> [Peer2]
[Peer1] -----( send )------> [Peer2] [HTTP Request [AS2-Message]]
[Peer1] <---( receive )----- [Peer2] [HTTP Response [AS2-MDN]]
Asynchronous AS2-MDN
异步AS2-MDN
[Peer1] ----( connect )----> [Peer2]
[Peer1] -----( send )------> [Peer2] [HTTP Request [AS2-Message]]
[Peer1] <---( receive )----- [Peer2] [HTTP Response]
[Peer1] ----( connect )----> [Peer2]
[Peer1] -----( send )------> [Peer2] [HTTP Request [AS2-Message]]
[Peer1] <---( receive )----- [Peer2] [HTTP Response]
[Peer1]*<---( connect )----- [Peer2]
[Peer1] <--- ( send )------- [Peer2] [HTTP Request [AS2-MDN]]
[Peer1] ----( receive )----> [Peer2] [HTTP Response]
[Peer1]*<---( connect )----- [Peer2]
[Peer1] <--- ( send )------- [Peer2] [HTTP Request [AS2-MDN]]
[Peer1] ----( receive )----> [Peer2] [HTTP Response]
* Note: An AS2-MDN may be directed to a host different from that of the sender of the AS2 message. It may utilize a transfer protocol different from that used to send the original AS2 message.
* 注意：AS2-MDN可能指向与AS2消息发送方不同的主机。它可以使用不同于用于发送原始AS2消息的传输协议。
The advantage of the synchronous MDN is that it can provide the sender of the AS2 Message with a verifiable confirmation of message delivery within a synchronous logic flow. However, if the message is relatively large, the time required to process this message and to return an AS2-MDN to the sender on the same TCP/IP connection may exceed the maximum configured time permitted for an IP connection.
同步MDN的优点是，它可以为AS2消息的发送者提供同步逻辑流中消息传递的可验证确认。但是，如果消息相对较大，则处理此消息以及在同一TCP/IP连接上将AS2-MDN返回给发送方所需的时间可能超过IP连接允许的最大配置时间。
The advantage of the asynchronous MDN is that it provides for the rapid return of a transfer-layer response from the receiver, confirming the receipt of data, therefore not requiring that a TCP/IP connection necessarily remain open for very long. However, this design requires that the asynchronous AS2-MDN contain enough information to identify the original message uniquely so that, when received by the AS2 Message originator, the status of the original AS2 Message can be properly updated based on the contents of the AS2-MDN.
异步MDN的优点是，它提供了从接收器快速返回传输层响应，从而确认数据的接收，因此不需要TCP/IP连接必须保持很长时间的打开状态。但是，这种设计要求异步AS2-MDN包含足够的信息，以唯一地标识原始消息，这样，当AS2消息发起人接收到原始AS2消息时，可以根据AS2-MDN的内容正确更新原始AS2消息的状态。
Synchronous or asynchronous HTTP or HTTPS MDNs are handled according to the requirements of this specification.
根据本规范的要求处理同步或异步HTTP或HTTPS MDN。
However, SMTP MDNs are formatted according to the requirements of RFC 3335 [4].
但是，SMTP MDN是根据RFC 3335[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" ":" mail-address
MDN request header=“处置通知到”“：”邮件地址
The following example is for requesting an MDN:
以下示例用于请求MDN：
Disposition-notification-to: xxx@example.com
处置通知：xxx@example.com
This syntax is a residue of the use of MDNs using SMTP transfer. Because this specification is adjusting the functionality from SMTP to HTTP while retaining as much as possible from the [4] functionality, the mail-address MUST be present. The mail-address field is specified as an RFC 2822 localpart@domain [addr-spec] address. However, the address is not used to identify where to return the MDN. Receiving applications MUST ignore the value and MUST not complain about RFC 2822 address syntax violations.
此语法是使用SMTP传输的MDN的残余。由于此规范将功能从SMTP调整为HTTP，同时尽可能保留[4]功能，因此邮件地址必须存在。邮件地址字段指定为RFC 2822localpart@domain[addr spec]地址。但是，该地址不用于标识返回MDN的位置。接收应用程序必须忽略该值，并且不得投诉RFC 2822地址语法冲突。
When requesting MDN-based receipts, the originator supplies additional extension headers that precede the message body. These header "tags" are as follows:
当请求基于MDN的回执时，发起者会在邮件正文之前提供额外的扩展标题。这些标题“标签”如下所示：
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 MDN. Other headers, especially "Subject" and "Date", SHOULD be supplied; the values of these headers are often mentioned in the human-readable section of a MDN to aid in identifying the original message.
添加了一个消息ID头以支持消息协调，因此可以在MDN的主体部分返回原始消息ID值。应提供其他标题，尤其是“主题”和“日期”；这些头的值通常在MDN的可读部分提到，以帮助识别原始消息。
MDNs will be returned in the HTTP response when requested, unless an asynchronous return is requested.
请求时，MDN将在HTTP响应中返回，除非请求异步返回。
To request an asynchronous message disposition notification, the following header is placed into the message that is sent:
要请求异步消息处置通知，将在发送的消息中放置以下标头：
Receipt-Delivery-Option: return-URL
收货交付选项：返回URL
Here is an example requesting that the MDN be asynchronous:
下面是一个请求MDN异步的示例：
Receipt-Delivery-Option: http://www.example.com/Path
Receipt-Delivery-Option: http://www.example.com/Path
Receipt-delivery-option syntax allows return-url to use some schemes other than HTTP using the POST method.
收货交付选项语法允许返回url使用POST方法使用HTTP以外的一些方案。
The "receipt-delivery-option: return-url" string indicates the URL to use for an asynchronous MDN. This header is NOT present if the receipt is to be synchronous. The email value in Disposition-notification-to is not used in this specification because it was limited to RFC 2822 addresses; the extension header "Receipt-delivery-option" has been introduced to provide a URL for the MDN return by several transfer options.
“收货交付选项：返回url”字符串表示用于异步MDN的url。如果要同步接收，则不存在此标题。本规范中未使用处置通知中的电子邮件值，因为它仅限于RFC 2822地址；引入了扩展标题“Receipt delivery option”，通过几个传输选项为MDN返回提供URL。
The receipt-delivery-option's value MUST be a URL indicating the delivery transport destination for the receipt.
收货交付选项的值必须是一个URL，指示收货的交付运输目的地。
An example request for an asynchronous MDN via an HTTP transport:
通过HTTP传输请求异步MDN的示例：
Receipt-delivery-option: http://www.example.com
Receipt-delivery-option: http://www.example.com
An example request for an asynchronous MDN via an HTTP/S transport:
通过HTTP/S传输请求异步MDN的示例：
Receipt-delivery-option: https://www.example.com
Receipt-delivery-option: https://www.example.com
An example request for an asynchronous MDN via an SMTP transport:
通过SMTP传输请求异步MDN的示例：
Receipt-delivery-option: mailto:as2@example.com
Receipt-delivery-option: mailto:as2@example.com
For more information on requesting SMTP MDNs, refer to RFC 3335 [4].
有关请求SMTP MDN的更多信息，请参阅RFC 3335[4]。
Finally, the header, Disposition-notification-options, identifies characteristics of message disposition notification as in [5]. The most important of these options is for indicating the signing options for the MDN, as in the following example:
最后，标题Disposition notification options标识消息处置通知的特征，如[5]所示。这些选项中最重要的是用于指示MDN的签名选项，如以下示例所示：
Disposition-notification-options: signed-receipt-protocol=optional,pkcs7-signature; signed-receipt-micalg=optional,sha1,md5
处置通知选项：签名接收协议=可选，pkcs7签名；签名收据micalg=可选，sha1，md5
For signing options, consider the disposition-notification-options syntax:
对于签名选项，请考虑处置通知选项语法：
Disposition-notification-options = "Disposition-Notification-Options" ":" disposition-notification-parameters
处置通知选项=“处置通知选项”：“处置通知参数”
where disposition-notification-parameters = parameter *(";" parameter)
其中处置通知参数=参数*（“；”参数）
where parameter = attribute "=" importance ", " 1#value"
其中参数=属性“=”重要性“，”1#值”
where
importance = "required" | "optional"
where
importance = "required" | "optional"
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 used value for <protocol symbol> is "pkcs7-signature" for the S/MIME detached signature format.
<protocol symbol>当前使用的值是S/MIME分离签名格式的“pkcs7签名”。
The currently supported values for MIC algorithm <micalg> values are:
MIC算法<micalg>值当前支持的值为：
Algorithm Value Used
--------- -------
SHA-1 sha1
MD5 md5
Algorithm Value Used
--------- -------
SHA-1 sha1
MD5 md5
The semantics of the "signed-receipt-protocol" and the "signed-receipt-micalg" parameters are as follows:
“签名接收协议”和“签名接收micalg”参数的语义如下：
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. The list of MIC algorithms SHOULD be honored by the recipient from left to right.
“signed receipt micalg”参数是请求者在签署返回的收据时首选的MIC算法列表。MIC算法列表应由接收者从左到右执行。
Both the "signed-receipt-protocol" and the "signed- receipt-micalg" option parameters are REQUIRED when requesting a signed receipt.
请求签名回执时，需要“签名回执协议”和“签名回执micalg”选项参数。
The lack of the presence of the "Receipt-Delivery-Option" indicates that a receipt is synchronous in nature. The presence of the "Receipt-Delivery-Option: return-url" indicates that an asynchronous receipt is requested and SHOULD be sent to the "return-url".
缺少“收货交付选项”表明收货本质上是同步的。“收货交付选项：返回url”的存在表示请求了异步收货，并应将其发送到“返回url”。
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 a MDN.
重要性为“可选”的参数允许不了解特定选项参数的UA仍然生成MDN以响应MDN请求。
A UA that does not understand the "signed-receipt-protocol" parameter or the "signed-receipt-micalg" will obviously not return a signed receipt.
不理解“签名收据协议”参数或“签名收据micalg”的UA显然不会返回签名收据。
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 and 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 is up to the trading partners to resolve.
在EDI交易关系中，如果预期会有一份已签署的收据，但没有返回，则交易的有效性取决于贸易伙伴来解决。
In general, if a signed receipt is required in 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" are as follows:
“规则”如下：
1. When a receipt is requested, explicitly specifying that the receipt be signed, then the receipt MUST be returned with a signature.
1. 当请求收据时，明确指定要签署收据，则必须返回带有签名的收据。
2. When a receipt is requested, explicitly specifying that the receipt be signed, but the recipient cannot support either the requested protocol format or the requested MIC algorithms, then either a signed or unsigned receipt SHOULD be returned.
2. 当请求收据时，明确指定要对收据进行签名，但收件人不能支持请求的协议格式或请求的MIC算法，则应返回已签名或未签名的收据。
3. 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.
3. 如果未明确请求签名，或者UA无法识别签名收据请求参数，则收件人可能不会返回收据、未签名收据或签名收据。
NOTE: For Internet EDI, it is RECOMMENDED that when a signature is not explicitly requested, or if parameters are not recognized, the UA send back, at a minimum, an unsigned receipt. If, however, a signed receipt was always returned as a policy, whether requested or not, then any false unsigned receipts can be repudiated.
注：对于Internet EDI，建议在未明确请求签名或未识别参数时，UA至少发回未签名收据。但是，如果签名收据始终作为策略返回（无论是否请求），则任何虚假的未签名收据都可以被拒绝。
When a request for a signed receipt is made, but there is an error in processing the contents of the message, a signed receipt MUST still be returned. The request for a signed receipt SHALL still be honored, though the transaction itself may not be valid. The reason why the contents could not be processed MUST be set in the "disposition-field".
当发出签名回执请求，但在处理邮件内容时出错时，仍必须返回签名回执。尽管交易本身可能无效，但签署收据的请求仍应得到满足。无法处理内容的原因必须在“处置字段”中设置。
When a signed receipt request is made, the "Received-content-MIC" MUST always be returned to the requester (except when corruption prevents computation of the digest in accordance with the following specification). The "Received-content-MIC" MUST be calculated as follows:
当发出签名的接收请求时，“接收到的内容MIC”必须始终返回给请求者（除非损坏导致无法根据以下规范计算摘要）。“接收内容MIC”必须按以下方式计算：
o For any signed messages, the MIC to be returned is calculated on the RFC1767/RFC3023 MIME header and content. Canonicalization on the MIME headers MUST be performed before the MIC is calculated, since the sender requesting the signed receipt was also REQUIRED to canonicalize.
o 对于任何已签名的消息，将根据RFC1767/RFC3023 MIME头和内容计算要返回的MIC。在计算MIC之前，必须对MIME头执行规范化，因为请求签名回执的发送方也需要进行规范化。
o For encrypted, unsigned messages, the MIC to be returned is calculated on the decrypted RFC 1767/RFC3023 MIME header and content. The content after decryption MUST be canonicalized before the MIC is calculated.
o 对于加密的、未签名的消息，将根据解密的RFC 1767/RFC3023 MIME头和内容计算要返回的MIC。解密后的内容必须在计算MIC之前规范化。
o For unsigned, unencrypted messages, the MIC MUST be calculated over the message contents without the MIME or any other RFC 2822 headers, since these are sometimes altered or reordered by Mail Transport Agents (MTAs).
o 对于未签名、未加密的邮件，由于邮件传输代理（MTA）有时会对邮件内容进行更改或重新排序，因此必须计算不带MIME或任何其他RFC 2822头的邮件内容的MIC。
This section defines the format of the AS2 Message Disposition Notification (AS2-MDN).
本节定义了AS2消息处置通知（AS2-MDN）的格式。
The AS2-MDN follows the MDN specification [5] except where noted in this section. The modified ABNF definitions in this document use the vertical-bar character, '|', to denote a logical "OR" construction. This usage follows RFC 2616 [3]. HTTP entities referred to below are not further defined in this document. Refer to RFC 2616 [3] for complete definitions of HTTP entities. The format of the AS2-MDN is:
AS2-MDN遵循MDN规范[5]，除非本节另有说明。本文件中修改后的ABNF定义使用竖线字符“|”，表示逻辑“或”结构。这种用法遵循RFC 2616[3]。本文件中未进一步定义下文提及的HTTP实体。有关HTTP实体的完整定义，请参阅RFC 2616[3]。AS2-MDN的格式为：
AS2-MDN = AS2-sync-MDN | AS2-async-http-MDN | AS2-async-smtp-MDN
AS2-MDN=AS2同步MDN | AS2异步http MDN | AS2异步smtp MDN
AS2-sync-MDN = Status-Line *(( general-header | response-header | entity-header ) CRLF ) CRLF AS2-MDN-body
AS2 sync MDN=状态行*（（一般标题|响应标题|实体标题）CRLF）CRLF AS2 MDN正文
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
状态行=HTTP版本SP状态代码SP原因短语CRLF
AS2-async-http-MDN = Request-Line *(( general-header | request-header | entity-header ) CRLF ) CRLF AS2-MDN-body
AS2异步http MDN=请求行*（（通用头|请求头|实体头）CRLF）CRLF AS2 MDN正文
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
请求行=方法SP请求URI SP HTTP版本CRLF
AS2-async-smtp-MDN = *(( general-header | request-header | entity-header ) CRLF ) CRLF AS2-MDN-body
AS2异步smtp MDN=*（（一般标头|请求标头|实体标头）CRLF）CRLF AS2 MDN正文
AS2-MDN-body = AS2-signed-MDN-body | AS2-unsigned-MDN-body
AS2 MDN正文=AS2有符号MDN正文| AS2无符号MDN正文
The AS2-MDN-body is formatted as a MIME multipart/report with a report-type of "disposition-notification". When the message is unsigned, the transfer-layer ("outermost") entity-headers of the AS2-MDN contain the content-type header that specifies a content-type
AS2 MDN正文的格式为MIME多部分/报告，报告类型为“处置通知”。当消息未签名时，AS2-MDN的传输层（“最外层”）实体头包含指定内容类型的内容类型头
of "multipart/report" and parameters indicating the report-type, and the value of the outermost multipart boundary.
“multipart/report”的值和指示报告类型的参数，以及最外面的multipart边界的值。
When the AS2-MDN is signed, the transfer-layer ("outermost") entity-headers of the AS2-MDN contain a content-type header that specifies a content-type of "multipart/signed" and 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 embedded MIME multipart/report of type "disposition-notification". The second part of the multipart/signed message contains a MIME application/pkcs7-signature message.
对AS2-MDN进行签名时，AS2-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多部分/报告的第二部分是“机器可读”部分，定义为：
AS2-disposition-notification-content =
[ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ]
final-recipient-field CRLF
[ original-message-id-field CRLF ]
AS2-disposition-field CRLF
*( failure-field CRLF )
*( error-field CRLF )
*( warning-field CRLF )
*( extension-field CRLF )
[ AS2-received-content-MIC-field CRLF ]
AS2-disposition-notification-content =
[ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ]
final-recipient-field CRLF
[ original-message-id-field CRLF ]
AS2-disposition-field CRLF
*( failure-field CRLF )
*( error-field CRLF )
*( warning-field CRLF )
*( extension-field CRLF )
[ AS2-received-content-MIC-field CRLF ]
The rules for constructing the AS2-disposition-notification content are identical to the disposition-notification-content rules provided in Section 7 of RFC 3798 [5], except that the RFC 3798 disposition-field has been replaced with the AS2-disposition-field and that the AS2-received-content-MIC field has been added. The differences between the RFC 3798 disposition-field and the AS2-disposition-field are described below. Where there are differences between this document and RFC 3798, those entity names have been changed by pre-pending "AS2-". Entities that do not differ from RFC 3798 are not necessarily further defined in this document; refer to RFC 3798, Section 7, "Collected Grammar", for the original grammar.
构建AS2处置通知内容的规则与RFC 3798[5]第7节中提供的处置通知内容规则相同，只是RFC 3798处置字段已替换为AS2处置字段，并且已添加AS2接收内容MIC字段。RFC 3798处置字段和AS2处置字段之间的差异如下所述。如果本文件与RFC 3798之间存在差异，则已通过预挂起的“AS2-”更改了这些实体名称。与RFC 3798无差异的实体不必在本文件中进一步定义；参考RFC 3798第7节“收集的语法”，了解原始语法。
AS2-disposition-field = "Disposition" ":" disposition-mode ";" AS2-disposition-type [ '/' AS2-disposition-modifier ]
AS2处置字段=“处置”“：“处置模式”；“AS2处置类型['/'AS2处置修饰符]
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"
AS2-disposition-type =
"processed" | "failed"
AS2-disposition-type =
"processed" | "failed"
AS2-disposition-modifier =
( "error" | "warning" ) | AS2-disposition-modifier-extension
AS2-disposition-modifier =
( "error" | "warning" ) | AS2-disposition-modifier-extension
AS2-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: " AS2-MDN-warning-description | "failure: " AS2-MDN-failure-description
AS2处置修饰符extension=“error:身份验证失败”|“error:解压缩失败”|“error:解密失败”|“error:消息安全性不足”|“error:完整性检查失败”|“error:意外处理错误”|“警告：”AS2 MDN警告说明|“failure:”AS2 MDN失败说明
AS2-MDN-warning-description = *( TEXT )
AS2-MDN-warning-description = *( TEXT )
AS2-MDN-failure-description = *( TEXT )
AS2-MDN-failure-description = *( TEXT )
AS2-received-content-MIC-field = "Received-content-MIC" ":" encoded-message-digest "," digest-alg-id CRLF
AS2接收内容麦克风字段=“接收内容麦克风”：“编码消息摘要”，“摘要alg id CRLF”
encoded-message-digest =
1*( 'A'-Z' | 'a'-'z' | '0'-'9' | '/' | '+' | '=' ) (
i.e. base64( message-digest ) )
encoded-message-digest =
1*( 'A'-Z' | 'a'-'z' | '0'-'9' | '/' | '+' | '=' ) (
i.e. base64( message-digest ) )
digest-alg-id = "sha1" | "md5"
digest-alg-id = "sha1" | "md5"
"Insufficient-message-security" and "decompression-failed" are new error codes that are not mentioned in the AS1 RFC 3335, and may not be compatible with earlier implementations of AS2.
“消息安全性不足”和“解压缩失败”是AS1 RFC 3335中未提及的新错误代码，可能与AS2的早期实现不兼容。
The "Received-content-MIC" extension field is set when 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.
验证接收到的消息的完整性时，将设置“接收到的内容麦克风”扩展字段。MIC是使用哈希函数对接收到的消息计算的base64编码消息摘要。此字段对于已签名的收据是必需的，但对于未签名的收据是可选的。有关定义用于计算消息摘要的特定内容的详细信息，请参阅本文件第7.3.1节。
For signed messages, the algorithm used to calculate the MIC MUST be the same as that used on the message that was signed. If the message is not signed, then the SHA-1 algorithm SHOULD be used. 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 so that the sender can verify non-repudiation of receipt.
对于已签名消息，用于计算MIC的算法必须与已签名消息上使用的算法相同。如果消息未签名，则应使用SHA-1算法。此字段仅在成功处理消息内容时设置。此字段与收件人在MDN上的签名一起使用，以便发件人可以验证收据的不可否认性。
AS2-MDN field names (e.g., "Disposition:", "Final-Recipient:") are case insensitive (cf. RFC 3798, Section 3.1.1). AS2-MDN action-modes, sending-modes, AS2-disposition-types, and AS2-disposition-modifier values, which are defined above, and user-supplied *( TEXT ) values are also case insensitive. AS2 implementations MUST NOT make assumptions regarding the values supplied for AS2-MDN-warning-description or AS2-MDN-failure-description, or for the values of any (optional) error, warning, or failure fields.
AS2-MDN字段名（例如，“处置：”、“最终收件人：”）不区分大小写（参见RFC 3798，第3.1.1节）。上面定义的AS2-MDN操作模式、发送模式、AS2处置类型和AS2处置修饰符值以及用户提供的*（文本）值也不区分大小写。AS2实现不得对为AS2 MDN警告描述或AS2 MDN故障描述提供的值，或任何（可选）错误、警告或故障字段的值进行假设。
o Unlike SMTP, for HTTP transactions, Original-Recipient and Final-Recipient SHOULD not be different. The value in Original-Message-ID SHOULD match the original Message-ID header value.
o 与SMTP不同，对于HTTP事务，原始收件人和最终收件人不应不同。原始邮件ID中的值应与原始邮件ID标头值匹配。
o Refer to RFC 3798 for the formatting of the MDN, except for the specific deviations mentioned above.
o 有关MDN的格式，请参考RFC 3798，上述特定偏差除外。
o Refer to RFC 3462 and RFC 3798 for the formatting of the content-type entity-headers for the MDN.
o 有关MDN的内容类型实体头的格式，请参阅RFC 3462和RFC 3798。
o Use an action-mode of "automatic-action" when the disposition described by the disposition type was a result of an automatic action rather than that of an explicit instruction by the user for this message.
o 当处置类型描述的处置是自动操作的结果，而不是用户对此消息的显式指令的结果时，请使用“自动操作”的操作模式。
o 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.
o 当处置类型描述的处置是用户明确指示的结果而不是某种自动执行的操作时，使用“手动操作”的操作模式。
o Use a sending-mode of "MDN-sent-automatically" when the MDN is sent because the UA had previously been configured to do so.
o 当发送MDN时，使用“MDN自动发送”的发送模式，因为UA先前已配置为这样做。
o Use a sending-mode of "MDN-sent-manually" when the user explicitly gave permission for this particular MDN to be sent.
o 当用户明确授予发送此特定MDN的权限时，请使用“手动发送MDN”的发送模式。
o The sending-mode "MDN-sent-manually" is meaningful ONLY with "manual-action", not with "automatic-action".
o 发送模式“MDN手动发送”仅对“手动操作”有意义，而对“自动操作”无意义。
o The "failed" disposition type MUST 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.
o “failed”处置类型不得用于处理消息时出现问题而不是解释MDN请求的情况。在这种情况下，应使用带有适当处置修饰符的“已处理”或其他处置类型。
This section provides a brief overview of how "processed", "error", "failure", and "warning" are used.
本节简要概述了如何使用“已处理”、“错误”、“失败”和“警告”。
When the request for a receipt or signed receipt, 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". 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.
当接收EDI UA成功处理收据或签名收据请求以及接收到的消息内容时，应返回收据或MDN，处置类型设置为“已处理”。当MDN由EDI UA自动发送，且用户没有明确的方式控制MDN的发送时，“处置模式”的第一部分应设置为“自动操作”。当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 the control of a user, administrator, or software.
如果用户对要发送的MDN授予明确的权限，则处置模式的第二部分设置为“手动发送MDN”。同样，当发送者请求发送签名收据时，不得允许用户明确拒绝发送签名收据。每当EDI UA自动发送MDN时，“处置模式”的第二部分设置为“自动发送MDN”，无论发送是在用户、管理员还是软件的控制下。
Because 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 that this specification does not restrict the use of the "disposition-mode" just to 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" values that should be used if the message content is being rejected or ignored (for instance, if the EDI UA determines that a signed receipt cannot be returned because it does not support the requested protocol format, the EDI UA chooses not to process the message contents itself) MUST be specified in the MDN "disposition-field" as follows:
签名回执请求需要使用两个“处置通知选项”，指定返回的签名回执的协议格式，以及用于计算消息内容上的MIC的MIC算法。MDN中必须指定在拒绝或忽略消息内容时应使用的“处置字段”值（例如，如果EDI UA确定签名回执无法返回，因为它不支持请求的协议格式，则EDI UA选择不处理消息内容本身）“处置字段”如下所示：
Disposition: "disposition-mode"; failed/Failure:
unsupported format
Disposition: "disposition-mode"; failed/Failure:
unsupported format
The "failed" AS2-disposition-type MUST be used when a failure occurs that prevents the proper generation of an MDN. For example, this disposition-type would apply if the sender of the message requested the application of an unsupported message-integrity-check (MIC) algorithm.
当发生阻止正确生成MDN的故障时，必须使用“failed”AS2处置类型。例如，如果邮件的发件人请求应用不受支持的邮件完整性检查（MIC）算法，则此处置类型将适用。
The "failure:" AS2-disposition-modifier-extension SHOULD be used with an implementation-defined description of the failure. Further information about the failure may be contained in a failure-field.
“failure:”AS2处置修饰符扩展应与实现定义的故障描述一起使用。有关故障的更多信息可包含在故障字段中。
The syntax of the "failed" disposition-type is general, allowing the sending of any textual information along with the "failed" disposition-type. Implementations MUST 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" MUST be set to the "processed" value for disposition-type and the "error" value for disposition-modifier.
处理收到的消息（内容除外）时出现错误时，必须将“处置字段”设置为处置类型的“已处理”值和处置修饰符的“错误”值。
The "error" AS2-disposition-modifier with the "processed" disposition-type MUST be used to indicate that an error of some sort occurred that prevented successful processing of the message. Further information may be contained in an error-field.
必须使用带有“已处理”处置类型的“error”AS2处置修饰符来指示发生了某种类型的错误，从而阻止了消息的成功处理。更多信息可能包含在错误字段中。
An "error:" AS2-disposition-modifier-extension SHOULD be used to combine the indication of an error with a predefined description of a specific, well-known error. Further information about the error may be contained in an error field.
“错误：”AS2处置修饰符扩展应用于将错误指示与特定已知错误的预定义描述相结合。有关错误的更多信息可能包含在错误字段中。
For internet EDI use, the following "error" AS2-disposition-modifier values are defined:
对于internet EDI使用，定义了以下“错误”AS2处置修饰符值：
o "Error: decryption-failed" - the receiver could not decrypt the message contents.
o “错误：解密失败”-接收方无法解密消息内容。
o "Error: authentication-failed" - the receiver could not authenticate the sender.
o “错误：身份验证失败”-接收方无法对发送方进行身份验证。
o "Error: integrity-check-failed" - the receiver could not verify content integrity.
o “错误：完整性检查失败”-接收器无法验证内容完整性。
o "Error: unexpected-processing-error" - a catch-all for any additional processing errors.
o “错误：意外处理错误”-任何其他处理错误的总括。
An example of how the "disposition-field" would look when errors other than those in content processing are detected is as follows:
当检测到除内容处理中的错误外的其他错误时，“处置字段”的外观示例如下：
Disposition: "disposition-mode"; processed/Error:
decryption-failed
Disposition: "disposition-mode"; processed/Error:
decryption-failed
Situations arise in EDI when, 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 as described above, the "disposition-field" MUST be set to the "processed" disposition-type value, and the "warning" to the "disposition-modifier" value.
处理警告情况如上所述，“处置字段”必须设置为“已处理”处置类型值，“警告”必须设置为“处置修饰符”值。
The "warning" AS2-disposition-modifier MUST be used with the "processed" disposition-type to indicate that the message was successfully processed but that an exceptional condition occurred. Further information may be contained in a warning-field.
“警告”AS2处置修饰符必须与“已处理”处置类型一起使用，以指示消息已成功处理，但出现异常情况。更多信息可能包含在警告字段中。
A "warning:" AS2-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.
“警告：”AS2处置修饰符扩展应用于将警告指示与实现定义的警告描述相结合。有关警告的更多信息可能包含在警告字段中。
For use in Internet EDI, the following "warning" disposition-modifier-extension value is defined:
为了在Internet EDI中使用，定义了以下“警告”处置修饰符扩展值：
"Warning: authentication-failed, processing continued"
警告：身份验证失败，处理继续
An example of how the "disposition-field" would look when warning other than those for content processing are detected is as follows:
当检测到除内容处理警告外的其他警告时，“处置字段”的外观示例如下：
Example:
例子：
Disposition: "disposition-mode"; processed/Warning:
authentication-failed, processing continued
Disposition: "disposition-mode"; processed/Warning:
authentication-failed, processing continued
7.5.6. Backward Compatibility with Disposition Type, Modifier, and Extension
7.5.6. 与处置类型、修饰符和扩展名的向后兼容性
The following set of examples represents typical constructions of the Disposition field that have been in use by AS2 implementations. This is NOT an exhaustive list of possible constructions. However, AS2 implementations MUST accept constructions of this type to be backward compatible with earlier AS2 versions.
下面的一组示例表示AS2实现中使用的Disposition字段的典型构造。这不是一个可能的构造的详尽列表。但是，AS2实现必须接受这种类型的构造才能与早期AS2版本向后兼容。
Disposition: automatic-action/MDN-sent-automatically; processed
Disposition: automatic-action/MDN-sent-automatically; processed
Disposition: automatic-action/MDN-sent-automatically;
processed/error: authentication-failed
Disposition: automatic-action/MDN-sent-automatically;
processed/error: authentication-failed
Disposition: automatic-action/MDN-sent-automatically;
processed/warning: duplicate-document
Disposition: automatic-action/MDN-sent-automatically;
processed/warning: duplicate-document
Disposition: automatic-action/MDN-sent-automatically;
failed/failure: sender-equals-receiver
Disposition: automatic-action/MDN-sent-automatically;
failed/failure: sender-equals-receiver
The following set of examples represents allowable constructions of the Disposition field that combine the historic constructions above with optional RFC 3798 error, warning, and failure fields. AS2 implementations MAY produce these constructions. However, AS2 servers are not required to recognize or process optional error, warning, or failure fields at this time. Note that the use of the multiple error fields in the second example below provides for the indication of multiple error conditions.
以下示例集表示处置字段的允许构造，该字段将上述历史构造与可选的RFC 3798错误、警告和故障字段相结合。AS2实现可能产生这些构造。但是，AS2服务器此时不需要识别或处理可选的错误、警告或故障字段。请注意，下面第二个示例中使用多个错误字段可以指示多个错误条件。
Disposition: automatic-action/MDN-sent-automatically; processed
Disposition: automatic-action/MDN-sent-automatically; processed
Disposition: automatic-action/MDN-sent-automatically; processed/error: decryption-failed Error: The signature did not decrypt into a valid PKCS#1 Type-2 block. Error: The length of the decrypted key does not equal the octet length of the modulus.
处置：自动动作/MDN自动发送；已处理/错误：解密失败错误：签名未解密为有效的PKCS#1 Type-2块。错误：解密密钥的长度不等于模数的八位字节长度。
Disposition: automatic-action/MDN-sent-automatically; processed/warning: duplicate-document Warning: An identical message already exists at the destination server.
处置：自动动作/MDN自动发送；已处理/警告：重复文档警告：目标服务器上已存在相同的消息。
Disposition: automatic-action/MDN-sent-automatically; failed/failure: sender-equals-receiver Failure: The AS2-To name is identical to the AS2-From name.
处置：自动动作/MDN自动发送；失败/失败：发送方等于接收方失败：AS2收件人名称与AS2发件人名称相同。
The following set of examples represents allowable constructions of the Disposition field that employ pure RFC 3798 Disposition-modifiers with optional error, warning, and failure fields. These examples are provided as informational only. These constructions are not guaranteed to be backward compatible with AS2 implementations prior to version 1.1.
下面的一组示例表示处置字段的允许构造，该字段使用纯RFC 3798处置修饰符，并带有可选的错误、警告和失败字段。这些示例仅供参考。这些构造不能保证与1.1版之前的AS2实现向后兼容。
Disposition: automatic-action/MDN-sent-automatically; processed
Disposition: automatic-action/MDN-sent-automatically; processed
Disposition: automatic-action/MDN-sent-automatically; processed/error Error: authentication-failed Error: The signature did not decrypt into a valid PKCS#1 Type-2 block. Error: The length of the decrypted key does not equal the octet length of the modulus.
处置：自动动作/MDN自动发送；已处理/错误：身份验证失败错误：签名未解密为有效的PKCS#1 Type-2块。错误：解密密钥的长度不等于模数的八位字节长度。
Disposition: automatic-action/MDN-sent-automatically;
processed/warning
Warning: duplicate-document
Disposition: automatic-action/MDN-sent-automatically;
processed/warning
Warning: duplicate-document
Disposition: automatic-action/MDN-sent-automatically; failed
Failure: sender-equals-receiver
Disposition: automatic-action/MDN-sent-automatically; failed
Failure: sender-equals-receiver
The details of the response to the POST command vary depending upon whether a receipt has been requested.
对POST命令的响应细节取决于是否已请求接收。
With no extended header requesting a receipt, and with no errors accessing the request-URI specified processing, the status line in the Response to the POST request SHOULD be in the 200 range. Status codes in the 200 range SHOULD also be used when an entity is returned (a signed receipt in a multipart/signed content type or an unsigned receipt in a multipart/report). Even when the disposition of the data was an error condition at the authentication, decryption or other higher level, the HTTP status code SHOULD indicate success at the HTTP level.
如果没有请求回执的扩展标头，并且在访问指定处理的请求URI时没有错误，则POST请求响应中的状态行应在200范围内。返回实体（多部分/已签名内容类型中的已签名收据或多部分/报告中的未签名收据）时，还应使用200范围内的状态代码。即使数据的处置在身份验证、解密或其他更高级别上是一个错误条件，HTTP状态代码也应该在HTTP级别指示成功。
The HTTP server-side application may respond with an unsolicited multipart/report as a message body that the HTTP client might not have solicited, but the client may discard this. Applications SHOULD avoid emitting unsolicited receipt replies because bandwidth or processing limitations might have led administrators to suspend asking for acknowledgements.
HTTP服务器端应用程序可能会以未经请求的多部分/报告作为HTTP客户端可能未请求的消息体进行响应，但客户端可能会放弃该消息体。应用程序应避免发出未经请求的回执回复，因为带宽或处理限制可能会导致管理员暂停请求确认。
Message Disposition Notifications, when used in the HTTP reply context, will closely parallel a SMTP MDN. For example, the disposition field is a required element in the machine-readable second part of a multipart/report for a MDN. The final-recipient-field ([5], Section 3.1) value SHOULD be derived from the entity headers of the request.
在HTTP应答上下文中使用消息处置通知时，将与SMTP MDN紧密并行。例如，disposition字段是MDN的多部分/报告的机器可读第二部分中的必需元素。最终收件人字段（[5]，第3.1节）的值应来自请求的实体头。
In an MDN, the first part of the multipart/report (the human-readable part) SHOULD include items such as the subject, the date, and other information when those fields are present in entity header fields following the POST request. An application MUST report the Message-ID of the request in the second part of the multipart/report (the machine-readable part). Also, an MDN SHOULD have its own unique Message-ID HTTP header. The HTTP reply SHOULD normally omit the third optional part of the multipart/report (used to return the original message or its headers in the SMTP context).
在MDN中，多部分/报告的第一部分（人类可读部分）应包括主题、日期和其他信息等项，当这些字段出现在POST请求后的实体标题字段中时。应用程序必须在多部分/报告的第二部分（机器可读部分）中报告请求的消息ID。此外，MDN应该有自己的唯一消息ID HTTP头。HTTP回复通常应省略多部分/报告的第三个可选部分（用于在SMTP上下文中返回原始邮件或其标题）。
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,
在短期内，公钥的交换和这些密钥的认证必须作为建立贸易伙伴关系过程的一部分来处理。UA和/或EDI应用程序接口必须维护用于加密或签名的公钥数据库，
in addition to the mapping between the EDI trading partner ID and the RFC 2822 [9] email address and HTTP URL/URI. The procedures for establishing a trading partnership and configuring the secure EDI messaging system might vary among trading partners and software packages.
除了EDI贸易伙伴ID与RFC 2822[9]电子邮件地址和HTTP 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. The use of a certification authority is therefore OPTIONAL. Certificates may be self-signed.
需要X.509证书。如果未使用约定的认证机构，建议贸易伙伴相互自我认证。本适用性声明不要求使用认证机构。因此，证书颁发机构的使用是可选的。证书可以是自签名的。
It is RECOMMENDED that when trading partners are using S/MIME they also exchange public key certificates, considering advice provided in [12].
考虑到[12]中提供的建议，建议贸易伙伴在使用S/MIME时也交换公钥证书。
The message formats useful for certificate exchange are found in [7] and [13].
[7]和[13]中提供了对证书交换有用的消息格式。
In the long term, additional standards may be developed to simplify the process of establishing a trading partnership, including the third-party authentication of trading partners, as well as the attributes of the trading relationship.
从长远来看，可以制定其他标准来简化建立贸易伙伴关系的过程，包括贸易伙伴的第三方认证以及贸易关系的属性。
This entire document is concerned with secure transport of business to business data, and it considers both data confidentiality and authentication issues.
整个文档涉及企业到企业数据的安全传输，它同时考虑了数据机密性和身份验证问题。
Extracted from RFC 3851 [7]: 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 Triple DES 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 of the relative cryptographic strength of messages.
摘自RFC3851[7]：大多数密码学家认为40位加密是弱加密。在S/MIME中使用弱加密技术在发送明文时几乎没有实际的安全性。但是，S/MIME的其他功能，如三重DES规范和向与您通信的各方宣布更强加密功能的能力，允许发件人创建使用强加密的消息。除非唯一的选择是不加密，否则永远不建议使用弱加密。在可行的情况下，发送和接收代理应通知发送方和接收方消息的相对加密强度。
Extracted from RFC 3850 [12]: 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 have not been listed, however, the reader should not assume
摘自RFC 3850[12]：在处理证书时，有许多情况下处理可能会失败。由于处理可能由用户代理、安全网关或其他程序完成，因此没有单一的方法来处理此类故障。然而，仅仅因为没有列出处理故障的方法，读者就不应该假设
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 situations in which signature and certificate checking might fail include the following:
签名和证书检查可能失败的许多情况包括：
o No certificate chain leads to a trusted CA.
o 没有证书链指向受信任的CA。
o No ability to check the Certificate Revocation List (CRL) for a certificate.
o 无法检查证书吊销列表（CRL）中的证书。
o An invalid CRL was received.
o 收到无效的CRL。
o The CRL being checked is expired.
o 正在检查的CRL已过期。
o The certificate is expired.
o 证书过期了。
o The certificate has been revoked.
o 证书已被吊销。
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. See RFC 3280 for additional information on certificate path validation.
当然，在其他情况下，证书可能是无效的，处理软件有责任彻底检查所有证书，并决定如果检查失败怎么办。有关证书路径验证的更多信息，请参阅RFC 3280。
The following are additional security considerations to those listed in [7] and [12].
以下是[7]和[12]中列出的安全注意事项之外的其他安全注意事项。
This specification seeks to provide multiple mechanisms that can be combined in accordance with local policies to achieve a wide range of security needs as determined by threat and risk analyses of the business peers. It is required that all these mechanisms be implemented by AS2 software so that the software has capabilities that promote strong interoperability, no matter what policies are adopted.
本规范旨在提供多种机制，这些机制可以根据本地策略进行组合，以实现由业务对等方的威胁和风险分析确定的广泛安全需求。要求所有这些机制都由AS2软件实现，以便无论采用何种策略，该软件都具有促进强互操作性的能力。
One strong cluster of mechanisms (the secure transmission loop) can provide good support for meeting the evidentiary needs of non-repudiation of receipt by the original sender and by a third party supplied with all stated evidence. However, this specification does not itself define non-repudiation of receipt nor enumerate its essential properties because NRR is a business analysis and/or legal requirement, and not relevantly defined by a technical applicability statement.
一个强大的机制集群（安全传输环路）可以提供良好的支持，以满足原始发送方和提供所有声明证据的第三方不否认接收的证据需求。然而，本规范本身并未定义收据的不可抵赖性，也未列举其基本属性，因为NRR是一项业务分析和/或法律要求，且未由技术适用性声明进行相关定义。
Some analyses observe that non-repudiation of receipt presupposes that non-repudiation of the sender of the original message is obtained, and further that non-repudiation should be implemented by means of digital signature on the original message. To satisfy strict NRR evidence, authentication and integrity MUST be provided by some mechanism, and the RECOMMENDED mechanism is digital signatures on both the original message and the receipt message.
一些分析观察到，收据的不可否认性假定原始电文的发送方获得不可否认性，并且应通过原始电文上的数字签名来实现不可否认性。为了满足严格的NRR证据，必须通过某种机制提供身份验证和完整性，推荐的机制是原始消息和接收消息上的数字签名。
Given that this specification has selected several mechanisms that can be combined in several ways, it is important to realize that if a digital signature is omitted from the original message, in order to satisfy the preceding analysis of NRR requirements, some authentication mechanism MUST accompany the request for a signed receipt and its included Received-content-MIC value. This authentication might come from using client-side SSL, authentication via IPsec, or HTTP authentication (while using SSL). In any case, records of the message content, its security basis, and the digest value need to be retained for the NRR process.
鉴于本规范选择了几种可以以多种方式组合的机制，必须认识到，如果从原始消息中省略了数字签名，为了满足前面对NRR要求的分析，某些身份验证机制必须与签名收据的请求及其包含的已接收内容MIC值一起提供。此身份验证可能来自使用客户端SSL、通过IPsec的身份验证或HTTP身份验证（使用SSL时）。在任何情况下，都需要为NRR流程保留消息内容、其安全基础和摘要值的记录。
Therefore, if NRR is one of the goals of the policy that is adopted, by using the mechanisms of the secure transmission loop mentioned above and by retaining appropriate records of authentication at the original message sender site, strong evidentiary requirements proposed for NRR can be fulfilled.
因此，如果NRR是所采用政策的目标之一，则通过使用上述安全传输环路的机制，并通过在原始消息发送方站点保留适当的认证记录，可以满足NRR的强烈证据要求。
Other ways of proceeding may fall short of fulfilling the most stringent sets of evidence required for NRR to obtain, but may nevertheless be part of a commercial trading agreement and, as such, are good enough for the parties involved. However, if MDNs are returned unsigned, evidentiary requirements for NRR are weak; some authentication of the identity of the receiver is needed.
其他诉讼方式可能无法满足NRR获取所需的最严格证据集，但可能仍然是商业贸易协议的一部分，因此，对相关各方来说已经足够好了。然而，如果MDN未经签名返回，则NRR的证据要求较弱；需要对接收者的身份进行某种验证。
The following certificate types MUST be supported for SSL server-side certificates:
SSL服务器端证书必须支持以下证书类型：
o with URL in the Distinguished Name Common Name attribute
o URL位于可分辨名称公共名称属性中
o without URL in the Distinguished Name Common Name attribute
o 可分辨名称公共名称属性中没有URL
o self-signed (self-issued)
o 自签（自发）
o certification authority certified
o 认证机构认证
The URL, which matches the source server identity, SHOULD be carried in the certificate. However, it is not required that DNS checks or reverse lookups to vouch for the accuracy of the URL or server value.
证书中应包含与源服务器标识匹配的URL。但是，不需要DNS检查或反向查找来保证URL或服务器值的准确性。
Because server-side certificates are exchanged, and also trust is established during the configuration of the trading partner relationship, runtime checks are not required by implementations of this specification.
由于交换服务器端证书，并且在配置贸易伙伴关系期间建立信任，因此本规范的实现不需要运行时检查。
The complete certification chain MUST be included in all certificates. All certificate verifications MUST "chain to root" or to an accepted trust anchor. Additionally, the certificate hash SHOULD match the hash recomputed by the receiver.
所有证书中必须包含完整的认证链。所有证书验证必须“链接到根”或接受的信任锚。此外，证书散列应与接收方重新计算的散列相匹配。
Because business data documents normally contain transaction ids, replays (such as resends of not-yet-acknowledged messages) are discarded as part of the normal process of duplicate detection. Detection of duplicates by Message-Id or by business transaction identifiers is recommended.
因为业务数据文档通常包含事务ID，所以作为重复检测的正常过程的一部分，将放弃重发（例如重新发送尚未确认的消息）。建议通过消息Id或业务事务标识符检测重复项。
RFC 3335 registered two Disposition-Notification-Options parameters
RFC 3335注册了两个处置通知选项参数
Parameter-name: signed-receipt-protocol Parameter-name: signed-receipt-micalg
参数名称：签字回执协议参数名称：签字回执micalg
that are also used by this specification (see Section 7.3).
本规范中也使用了（见第7.3节）。
RFC 3335 also registered on MDN Extension field name
RFC 3335也在MDN扩展字段名上注册
Extension field name: Received-content-MIC
扩展字段名称：已接收内容麦克风
that is also used by this specification (see Section 7.4.3). Registration of the above is therefore NOT needed.
本规范中也使用了这一点（见第7.4.3节）。因此，不需要对上述各项进行登记。
This specification defines an extension to the Message Disposition Notification (MDN) protocol for a disposition-modifier in the Disposition field of a body of content-type "message/disposition-notification".
本规范为内容类型为“消息/处置通知”的主体的处置字段中的处置修饰符定义了消息处置通知（MDN）协议的扩展。
Parameter-name: warning Semantics: See Sections 7.4.3 and 7.5.5 of this document.
参数名称：警告语义：见本文件第7.4.3节和第7.5.5节。
Carl Hage, Karen Rosenfeld, Chuck Fenton, and many others have provided valuable suggestions that improved this applicability statement. The authors would also like to thank the vendors who participated in the Drummond Group Inc. AS2 interoperability testing. Their contributions led to great improvement in the clarity of this document.
Carl Hage、Karen Rosenfeld、Chuck Fenton和许多其他人提供了有价值的建议，改进了该适用性声明。作者还要感谢参与Drummond Group Inc.AS2互操作性测试的供应商。他们的贡献大大提高了本文件的清晰度。
[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] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[3] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[4] Harding, T., Drummond, R., and C. Shih, "MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet", RFC 3335, September 2002.
[4] Harding，T.，Drummond，R.，和C.Shih，“互联网上基于MIME的安全对等业务数据交换”，RFC 3335，2002年9月。
[5] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[5] Hansen，T.和G.Vaudreuil，“消息处置通知”，RFC 3798，2004年5月。
[6] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[6] Galvin，J.，Murphy，S.，Crocker，S.，和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[7] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[8] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[8] Vaudreuil，G.“邮件系统管理消息报告的多部分/报告内容类型”，RFC 3462，2003年1月。
[9] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[9] Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[10] Murata, M., Laurent, S. St., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[10] Murata，M.，Laurent，S.St.，和D.Kohn，“XML媒体类型”，RFC3023，2001年1月。
[11] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[11] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[12] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[12] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1证书处理”，RFC 38502004年7月。
[13] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[13] Housley，R.，“加密消息语法（CMS）”，RFC3852，2004年7月。
[14] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[14] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[15] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
Appendix A: Message Examples
附录A：信息示例
NOTE: All examples are provided for illustration only, and are not considered part of the protocol specification. If an example conflicts with the protocol definitions specified above or in the other referenced RFCs, the example is wrong.
注：所有示例仅用于说明，不属于协议规范的一部分。如果示例与上述或其他参考RFC中指定的协议定义冲突，则示例是错误的。
POST /receive HTTP/1.0
Host: 10.234.160.12:80
User-Agent: AS2 Company Server
Date: Wed, 31 Jul 2002 13:34:50 GMT
From: mrAS2@example.com
AS2-Version: 1.1
AS2-From: "\" as2Name \""
AS2-To: 0123456780000
Subject: Test Case
Message-Id: <200207310834482A70BF63@\"~~foo~~\">
Disposition-Notification-To: mrAS2@example.com
Disposition-Notification-Options: signed-receipt-protocol=optional,
pkcs7-signature; signed-receipt-micalg=optional,sha1
Content-Type: multipart/signed; boundary="as2BouNdary1as2";
protocol="application/pkcs7-signature"; micalg=sha1
Content-Length: 2464
POST /receive HTTP/1.0
Host: 10.234.160.12:80
User-Agent: AS2 Company Server
Date: Wed, 31 Jul 2002 13:34:50 GMT
From: mrAS2@example.com
AS2-Version: 1.1
AS2-From: "\" as2Name \""
AS2-To: 0123456780000
Subject: Test Case
Message-Id: <200207310834482A70BF63@\"~~foo~~\">
Disposition-Notification-To: mrAS2@example.com
Disposition-Notification-Options: signed-receipt-protocol=optional,
pkcs7-signature; signed-receipt-micalg=optional,sha1
Content-Type: multipart/signed; boundary="as2BouNdary1as2";
protocol="application/pkcs7-signature"; micalg=sha1
Content-Length: 2464
--as2BouNdary1as2 Content-Type: application/edi-x12 Content-Disposition: Attachment; filename=rfc1767.dat [ISA ...EDI transaction data...IEA...]
--as2BouNdary1as2内容类型：应用程序/edi-x12内容处置：附件；filename=rfc1767.dat[ISA…EDI事务数据…IEA…]
--as2BouNdary1as2 Content-Type: application/pkcs7-signature
--as2BouNdary1as2内容类型：应用程序/pkcs7签名
[omitted binary pkcs7 signature data] --as2BouNdary1as2--
[省略的二进制pkcs7签名数据]--as2BouNdary1as2--
HTTP/1.0 200 OK
AS2-From: 0123456780000
AS2-To: "\" as2Name \""
AS2-Version: 1.1
Message-ID: <709700825.1028122454671.JavaMail@ediXchange>
Content-Type: multipart/signed; micalg=sha1;
protocol="application/pkcs7-signature";
boundary="----=_Part_57_648441049.1028122454671"
Connection: Close
HTTP/1.0 200 OK
AS2-From: 0123456780000
AS2-To: "\" as2Name \""
AS2-Version: 1.1
Message-ID: <709700825.1028122454671.JavaMail@ediXchange>
Content-Type: multipart/signed; micalg=sha1;
protocol="application/pkcs7-signature";
boundary="----=_Part_57_648441049.1028122454671"
Connection: Close
Content-Length: 1980
内容长度：1980年
------=_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@\"~~foo~~\">
& From: "\" as2Name \""
& To: "0123456780000"
& 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: AS2 Server
&Original-Recipient: rfc822; 0123456780000
&Final-Recipient: rfc822; 0123456780000
&Original-Message-ID: <200207310834482A70BF63@\"~~foo~~\">
&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@\"~~foo~~\">
& From: "\" as2Name \""
& To: "0123456780000"
& 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: AS2 Server
&Original-Recipient: rfc822; 0123456780000
&Final-Recipient: rfc822; 0123456780000
&Original-Message-ID: <200207310834482A70BF63@\"~~foo~~\">
&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 the "S/MIME Message Specification, PKCS Security Services for MIME".)
2. 有关如何准备multipart/signed with protocol=“application/pkcs7 signature”的详细信息，请参阅“S/MIME消息规范，PKCS Security Services For MIME”。）
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 [8], 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[8]的规定，不需要在多部分/报告的第三个正文部分中返回原始消息的原件或部分内容。这是可选的身体部位。但是，建议省略或留空此车身零件。
A.3. Signed, Encrypted Message Requesting a Signed, Asynchronous Receipt
A.3. 已签名的加密邮件，请求已签名的异步回执
Message-ID: <#as2_company#01#a4260as2_companyout#>
Date: Thu, 19 Dec 2002 15:04:18 GMT
From: me@example.com
Subject: Async MDN request
Mime-Version: 1.0
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename=smime.p7m
Recipient-Address: 10.240.1.2//
Disposition-Notification-To:
http://10.240.1.2:8201/exchange/as2_company
Disposition-Notification-Options: signed-receipt-protocol=optional,
pkcs7-signature; signed-receipt-micalg=optional,sha1
Receipt-Delivery-Option:
http://10.240.1.2:8201/exchange/as2_company
AS2-From: as2_company
AS2-To: "AS2 Test"
AS2-Version: 1.1
Host: 10.240.1.2:8101
Connection: close
Content-Length: 3428
Message-ID: <#as2_company#01#a4260as2_companyout#>
Date: Thu, 19 Dec 2002 15:04:18 GMT
From: me@example.com
Subject: Async MDN request
Mime-Version: 1.0
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename=smime.p7m
Recipient-Address: 10.240.1.2//
Disposition-Notification-To:
http://10.240.1.2:8201/exchange/as2_company
Disposition-Notification-Options: signed-receipt-protocol=optional,
pkcs7-signature; signed-receipt-micalg=optional,sha1
Receipt-Delivery-Option:
http://10.240.1.2:8201/exchange/as2_company
AS2-From: as2_company
AS2-To: "AS2 Test"
AS2-Version: 1.1
Host: 10.240.1.2:8101
Connection: close
Content-Length: 3428
[omitted binary encrypted data]
[省略的二进制加密数据]
POST / HTTP/1.1
Host: 10.240.1.2:8201
Connection: close, TE
TE: trailers, deflate, gzip, compress
User-Agent: RPT-HTTPClient/0.3-3I (Windows 2000)
Date: Thu, 19 Dec 2002 15:03:38 GMT
Message-ID: <AS2-20021219_030338@as2_company.dgi_th>
AS2-Version: 1.1
Mime-Version: 1.0
Recipient-Address:
http://10.240.1.2:8201/exchange/as2_company
AS2-To: as2_company
AS2-From: "AS2 Test"
Subject: Your Requested MDN Response
From: as2debug@example.com
Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress
Content-Type: multipart/signed; micalg=sha1;
protocol="application/pkcs7-signature";
boundary="----=_Part_337_6452266.1040310218750"
Content-Length: 3103
POST / HTTP/1.1
Host: 10.240.1.2:8201
Connection: close, TE
TE: trailers, deflate, gzip, compress
User-Agent: RPT-HTTPClient/0.3-3I (Windows 2000)
Date: Thu, 19 Dec 2002 15:03:38 GMT
Message-ID: <AS2-20021219_030338@as2_company.dgi_th>
AS2-Version: 1.1
Mime-Version: 1.0
Recipient-Address:
http://10.240.1.2:8201/exchange/as2_company
AS2-To: as2_company
AS2-From: "AS2 Test"
Subject: Your Requested MDN Response
From: as2debug@example.com
Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress
Content-Type: multipart/signed; micalg=sha1;
protocol="application/pkcs7-signature";
boundary="----=_Part_337_6452266.1040310218750"
Content-Length: 3103
------=_Part_337_6452266.1040310218750
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="----=_Part_336_6069110.1040310218718"
------=_Part_337_6452266.1040310218750
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="----=_Part_336_6069110.1040310218718"
------=_Part_336_6069110.1040310218718
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
------=_Part_336_6069110.1040310218718
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The message <x12.edi> sent to Recipient <AS2 Test> on Thu, 19 Dec 2002 15:04:18 GMT with Subject <async MDN request> has been received. The EDI Interchange was successfully decrypted, and its integrity was verified. In addition, the sender of the message, Sender <as2_company> at Location http://10.240.1.2:8201/exchange/as2_company was authenticated as the originator of the message. There is no guarantee, however, that the EDI interchange was syntactically correct, or that it was received by the EDI application/translator.
已收到2002年12月19日星期四15:04:18 GMT发送给收件人的主题为“异步MDN请求”的消息<x12.edi>。EDI交换已成功解密，其完整性已得到验证。此外，消息的发送者，发送者<as2_company>，位于http://10.240.1.2:8201/exchange/as2_company 已作为邮件的原始发件人进行身份验证。但是，不能保证EDI交换在语法上是正确的，或者EDI应用程序/翻译程序收到了该交换。
------=_Part_336_6069110.1040310218718
Content-Type: message/disposition-notification
Content-Transfer-Encoding: 7bit
------=_Part_336_6069110.1040310218718
Content-Type: message/disposition-notification
Content-Transfer-Encoding: 7bit
Reporting-UA: AS2@test:8101
Original-Recipient: rfc822; "AS2 Test"
Final-Recipient: rfc822; "AS2 Test"
Original-Message-ID: <#as2_company#01#a4260as2_companyout#>
Disposition: automatic-action/MDN-sent-automatically;
processed
Received-Content-MIC: Hes6my+vIxIYxmvsA+MNpEOTPAc=, sha1
Reporting-UA: AS2@test:8101
Original-Recipient: rfc822; "AS2 Test"
Final-Recipient: rfc822; "AS2 Test"
Original-Message-ID: <#as2_company#01#a4260as2_companyout#>
Disposition: automatic-action/MDN-sent-automatically;
processed
Received-Content-MIC: Hes6my+vIxIYxmvsA+MNpEOTPAc=, sha1
------=_Part_336_6069110.1040310218718--
------=_Part_336_6069110.1040310218718--
------=_Part_337_6452266.1040310218750
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
------=_Part_337_6452266.1040310218750
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
BhbWjEfbyXoTAS/H0zpnEqLqbaBh29y2v82b8bdeGw8pipBQWmf53hIcqHGM 4ZBF3CHw5Wrf1JIE+8TwOzdbal30zeChw88WfRfD7c/j1fIA8sxsujvf2d9j UxCUga8BVdVB9kH0Geexytyt0KvWQXfaEEcgZGUAAAAAAAA=
BhbWjEfbyXoTAS/H0zpnEqLqbaBh29y2v82b8bdeGw8pipBQWmf53hIcqHGM 4ZBF3CHw5Wrf1JIE+8TwOzdbal30zeChw88WfRfD7c/j1fIA8sxsujvf2d9j UXCUGA8BVD9KH0GEEXYTYT0KVWQXFAEGZGUAAAAAAAAA=
------=_Part_337_6452266.1040310218750-
------=_Part_337_6452266.1040310218750-
Authors' Addresses
作者地址
Dale Moberg Cyclone Commerce 8388 E. Hartford Drive, Suite 100 Scottsdale, AZ 85255 USA
Dale Moberg Cyclone Commerce 8388美国亚利桑那州斯科茨代尔哈特福德大道东100号套房，邮编85255
EMail: dmoberg@cyclonecommerce.com
EMail: dmoberg@cyclonecommerce.com
Rik Drummond Drummond Group Inc. 4700 Bryant Irvin Court, Suite 303 Fort Worth, TX 76107 USA
Rik Drummond Drummond Group Inc.位于美国德克萨斯州沃思堡303室Bryant Irvin Court 4700号，邮编76107
EMail: rvd2@drummondgroup.com
EMail: rvd2@drummondgroup.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。