[要約] RFC 4130は、MIMEベースのセキュアなピアツーピアのビジネスデータの交換をHTTPを使用して行うための規格です。このRFCの目的は、AS2プロトコルの適用性を示し、ビジネス間のデータの安全な転送を実現することです。
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).
Copyright（c）The Internet Society（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.
このドキュメントは、SMTPの代わりにHTTP転送プロトコルを使用して構造化されたビジネスデータを安全に交換する方法を説明する適用可能性ステートメント（RFC 2026、セクション3.2）を提供します。SMTPの適用性ステートメントはRFC 3335にあります。構造化されたビジネスデータはXMLである可能性があります。American National Standards Committee（ANSI）X12形式のいずれかの電子データインターチェンジ（EDI）または管理、商業、および輸送（UN/EDIFACT）形式のための国連電子データ交換。または他の構造化データ形式。データは、標準のMIME構造を使用してパッケージ化されています。認証とデータの機密性は、S/MIMEセキュリティボディパーツを持つ暗号化メッセージ構文を使用して取得されます。認証された謝辞元のHTTPメッセージに対するマルチパート/署名メッセージ処分通知（MDN）応答を使用します。この適用声明は、「AS2」と呼ばれる非公式に「AS2」と呼ばれます。これは、「AS1」、RFC 3335の後に作成された2番目の適用性ステートメントであるためです。
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
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.
インターネット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:
インターネット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 RFCS 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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [13]に記載されているように解釈される。
AS2: Applicability Statement 2 (this document); see RFC 2026 [11], Section 3.2
AS2：Applicability Statement 2（このドキュメント）;RFC 2026 [11]、セクション3.2を参照してください
EDI: Electronic Data Interchange
EDI：電子データインターチェンジ
EC: Business-to-Business Electronic Commerce
EC：企業間の電子商取引
B2B: Business to Business 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.
B2B：ビジネスからビジネスへの領収書：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）：領収書を伝えるために使用されるインターネットメッセージング形式。この用語は、領収書と同じ意味で使用されます。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：インターネット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ポスト操作[3]は、適切にパッケージ化されたEDI、XML、またはその他のビジネスデータを送信するために使用されます。Request-URI（[3]、セクション9.5）は、メッセージデータを開梱して処理するプロセスと、署名または署名のいずれかのメッセージ処分確認（MDN）を含むクライアントの返信を生成するためのプロセスを識別します。MDNは、HTTP応答メッセージ本文で、または元の送信者のURLへの新しいHTTP Post操作によって返されます。
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.
このドキュメントの焦点は、インターネットの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 requests a signed receipt, and later the receiving organization sends this signed receipt back to the sending organization. In other words, the following transpires:
EDI/ECの「Secure Transmission Loop」では、ある組織が署名済みおよび暗号化されたEDI/ECインターチェンジを別の組織に送信し、署名入りの領収書を要求し、その後、受信組織はこの署名済みの領収書を送信組織に送り返します。言い換えれば、次のことが延期されます。
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 S/MIMEを使用してEDI/ECデータサインを送信し、データを暗号化する組織。さらに、メッセージは、署名済みの領収書を送信者に返送することを要求します。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 Reply Bodyまたは別のHTTPポスト操作を使用して、署名されたメッセージ処分通知の形で送信組織に署名された領収書を返します。この署名された領収書には、受信したメッセージのハッシュが含まれているため、元の送信者が受信したメッセージが受信者によって認証され、および/または適切に復号化されたという証拠を持つことができます。
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インターチェンジの配信を認めるためのメッセージの両方に使用される用語は、「領収書」または「署名領収書」です。最初の用語は、承認がインターチェンジの場合に使用され、署名されていない領収書になります。2番目の用語は、承認がインターチェンジ用である場合に使用され、署名された領収書になります。
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.
領収書の非repudiation（NRR）という用語は、多くの場合、領収書と組み合わせて使用されます。NRRとは、インターチェンジの元の送信者がメッセージの受信者から戻ってくる署名領収書を確認し、MDN内の返されたマイク値が元のメッセージの以前に記録された値と一致することを確認した場合にのみ発生する法的イベントを指します。
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のセグメントが確保されていることを意味します。edifactでは、これは、セグメント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ネットワーク（付加価値ネットワークまたはバンと呼ばれる）からインターネットへのルーティングを最適化するには、エンベロープ情報を表示できるようにすることが役立ちます。ただし、この仕様は、この最適化をサポートしていません。
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はエディファクトのセキュリティを提供します。この仕様は、これらのセキュリティ基準の使用または不使用を決定するものではありません。これらは両方とも、この仕様とは冗長性であるかもしれませんが、完全に互換性があります。
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メッセージ送信が可能になります。署名された領収書通知が要求されます。ただし、重度の誤差条件がダイジェスト値の計算を防ぐ場合を除き、返された領収書の一部としてマイク値が必要です。例外的な場合、署名済みの領収書は、マイクが存在しない理由を効果的に説明するエラーメッセージで返品する必要があります。
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:
要約すると、特定の取引関係で次の12のセキュリティ順列が可能です。
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の可能性を選択できますが、最後の例（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のセキュリティマルチパート：MultiPart/暗号化およびマルチパート/署名を定義しています。
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（Application/EDI-X12）、Edifact（Application/Edifact）、および相互に定義されたEDI（Application/EDI-Consent）のコンテンツタイプ「アプリケーション」の使用を定義します。
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関連のRFCが構築する基本的なMIME基準です。重要な貢献には、「コンテンツタイプ」、「サブタイプ」、「マルチパート」の定義、およびインターネットメッセージングで使用される標準文字セットとして7ビットのUS-ASCIIを確立するエンコードガイドラインが含まれます。
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.
このインターネットRFCは、MDNがどのように要求されるか、およびMDNの形式と構文を定義します。MDNは、この仕様で領収書と署名された領収書が定義される根拠です。
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）のコンテンツタイプ「アプリケーション」の使用を定義します。
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に準拠してコーディングする方法の詳細については、参照されているRFCSに直接目を向けます。AS2移植とRFCの違いは、以下のセクションで特に言及されています。
No encryption, no signature -RFC2616/2045 -RFC1767/RFC3023 (application/EDIxxxx or /xml)
暗号化なし、署名なし-RFC2616/2045 -RFC1767/RFC3023（Application/Edixxxxまたは/xml）
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, 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)
HTTPを介したMDN、署名-RFC2616/2045 -RFC1847（MultiPart/Signed）-RFC3798（Message/Dais -Notification）-RFC3851（Application/PKCS7 -Signature）
MDN over SMTP, no signature MDN over SMTP, signature Refer to the EDI over SMTP standard [4].
SMTPを介したMDN、SMTP上の署名MDNなし、署名はSMTP標準上のEDIを参照しています[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: 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).
リクエスト行には、「リクエスト-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を使用してマルチパート/署名されたメッセージ本文のみが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システムから切断される場合があります。
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永続的な接続はデフォルトです（[3]セクション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ボディパートのコンテンツ転送エンコードも許可されています。
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]:
Message-IDおよびOriginal-Message-IDは、RFC 2822 [9]で定義されているようにフォーマットされています。
"<" 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文字以下でなければなりません。Message-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リクエストに含める必要があります。このフィールドは、1つのサーバー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.
Request-URIのエラー、400（「悪いリクエスト」）、404（ "not not"）、および同様のコードは適切なステータスコードです。これらのコードとそのセマンティクスは[3]で指定されています。再試行機能を実装する前に、これらのコードとそれらのセマンティクスを慎重に調べる必要があります。エラーが一時的でない場合、またはRETRIRIESが明示的に落胆している場合は、再試行を行わないでください。
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を含む同一のコンテンツを持つポスト操作を繰り返す必要があります。
The Message-ID on a POST operation can be reused if and only if all of the content (including the original Date) is identical.
すべてのコンテンツ（元の日付を含む）が同一である場合にのみ、ポスト操作のメッセージ-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で投稿を受信するために準備する必要があります。MDNやその他のMimeパーツを含む、以前に送信されたMime Reply Bodyはresります。
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].
次のヘッダーは、SMTPを使用して送信され、AS1セマンティクスに従う非同期MDNを除き、すべてのAS2メッセージおよびすべてのAS2 MDNSに含める必要があります[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 -version：1.0-この仕様のすべての実装で使用されます。1.xは、「AS2バージョン：1.0」ヘッダーを使用して、すべての実装によって1.0と解釈されます。つまり、追加の非AS2指定機能を実装していない人のバージョン識別子として最も重要な数字のみが使用されます。「AS2-version：1.0〜1.9」を使用できます。すべての実装は、この仕様の実装として「1.0〜1.9」を解釈する必要があります。ただし、実装は、バージョン1.1〜1.9を指定することにより、追加の機能でこの仕様を拡張する場合があります。このメカニズムを使用する場合、追加の機能は、「AS2-version：1.0」指定を使用して実装に対して完全に透過的でなければなりません。
AS2-Version: 1.1 - Designates those implementations that support compression as defined by RFC 3274.
AS2 -version：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-versionヘッダーが存在しないため、受信システムが失敗してはなりません。その不在は、メッセージがこの仕様の以前のバージョンに基づく実装からのものであることを示します。
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 >
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-qtext = AS2-text / SP ; allow space only in quoted text
AS2-quoted-pair = "\" DQUOTE / ; \" or
"\" "\" ; \\
AS2-quoted-name = DQUOTE 1*128( AS2-qtext /
AS2-quoted-pair) DQUOTE
AS2-atomic-name = 1*128AS2-text
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からヘッダー値はそれぞれAS2-NAMEでなければならず、それぞれが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-quoted-nameは、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.
SMTPを使用して送信される非同期MDNを除き、本質的に非同期であるか同期しているかどうかにかかわらず、AS2-to 2-as2-fromヘッダーフィールドは、本質的に非同期または同期しているかどうかにかかわらず、AS2 MDNSに存在する必要があります。
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-NAMEは、対応するリクエストメッセージのAS2-FROMヘッダーのAS2-NAMEと一致する必要があります。同様に、応答またはMDNのAS2-FROMヘッダーのAS2-NAMEは、対応するAS2要求メッセージのAS2-toヘッダーのAS2-NAMEと一致する必要があります。
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-to/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からヘッダー値を含むクライアントリクエストには必要な応答はありません。受信AS2システムは、送信システムがMDNを要求した場合、エラーの説明を記載した署名のない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. マルチパート/レポートを作成する機能。ここで、レポート-Type =処分 - 解釈。
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）を計算する機能。計算されたマイク値は、署名された領収書内のメッセージの送信者に返されます。
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. メッセージ処分通知を使用して最初のボディパーツとして、および2番目のボディパートとしての署名を使用して、マルチパート/署名されたコンテンツを作成する機能。
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. メッセージの整合性チェック（マイクまたはメッセージダイジェスト）は、送信者の公開キーを使用して復号化されます。
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オブジェクト）のマイクは、送信する取引パートナーが使用したのと同じ一方向ハッシュ関数を使用して計算されます。
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が計算されます。
4. The receiving trading partner formats the MDN and sets the calculated MIC into the "Received-content-MIC" extension field.
4. 受信トレーディングパートナーはMDNをフォーマットし、計算されたマイクを「受信コンテンツマイク」拡張フィールドに設定します。
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はMultiPart/署名されたメッセージの最初の部分であり、MIMEヘッダーを含むこのMDNにデジタル署名が作成されます。
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/署名されたメッセージの2番目の部分には、デジタル署名が含まれています。マルチパート/署名の第2部で指定された「プロトコル」オプションは次のとおりです。
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インターチェンジとRFC 1767 MIME EDIコンテンツヘッダーは、実際にはマルチパートMIMEコンテンツタイプの一部になります。EDIインターチェンジがマルチパートMIMEコンテンツタイプの一部である場合、MIMEヘッダーを含むマルチパートコンテンツ全体でマイクを計算する必要があります。
The signed MDN, when received by the sender of the EDI Interchange, can be used by the sender as follows:
署名されたMDNは、EDIインターチェンジの送信者が受信した場合、次のように送信者が使用できます。
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の「受信コンテンツマイック」フィールドで受信したECインターチェンジ（および1767 MIMEヘッダー）の計算マイクを返すことにより、これを行います。
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内の返されたマイク値は、元のメッセージのダイジェストと同じです。
The AS2-MDN exists in two varieties: synchronous and asynchronous.
AS2-MDNは、同期と非同期の2つの品種に存在します。
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接続でポストの発信元に返されるため、同期と呼ばれます。
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、HTTP、またはSMTP TCP/IP接続で送信されます。論理的には、非同期AS2-MDNはAS2メッセージへの応答です。ただし、Transfer-Protocol層では、HTTPパイプラインが使用されないと仮定すると、非同期AS2-MDNは、元のAS2メッセージを配信するために使用されるものとは異なる一意のTCP/IP接続で配信されます。非同期リクエストを処理する場合、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]]
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-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メッセージの送信者に同期ロジックフロー内でのメッセージ配信の検証可能な確認を提供できることです。ただし、メッセージが比較的大きい場合、このメッセージを処理してAS2-MDNを同じTCP/IP接続で送信者に返すのに必要な時間は、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。
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 = "dision-notification-to" "："メールアドレス
The following example is for requesting an MDN:
次の例は、MDNをリクエストするためのものです。
Disposition-notification-to: xxx@example.com
気質 - notification to：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転送を使用したMDNSの使用の残基です。この仕様は、[4]機能から可能な限り保持しながら、SMTPからHTTPへの機能を調整しているため、メールアドレスが存在する必要があります。メールアドレスフィールドは、RFC 2822 LocalPart@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ベースの領収書を要求するとき、Originatorはメッセージ本文の前に追加の追加の拡張ヘッダーを提供します。これらのヘッダー「タグ」は次のとおりです。
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.
非同期リターンが要求されない限り、MDNSは要求されたときにHTTP応答で返されます。
To request an asynchronous message disposition notification, the following header is placed into the message that is sent:
非同期メッセージ処分通知を要求するには、次のヘッダーが送信されるメッセージに配置されます。
Receipt-Delivery-Option: return-URL
領収書配信オプション：Return-URL
Here is an example requesting that the MDN be asynchronous:
MDNが非同期であることを要求する例は次のとおりです。
Receipt-Delivery-Option: http://www.example.com/Path
領収書 - 配信オプション：http：//www.example.com/path
Receipt-delivery-option syntax allows return-url to use some schemes other than HTTP using the POST method.
Receipt-Divery-Optionの構文により、Return-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.
「Receipt-Divery-Option：Return-URL」文字列は、非同期MDNに使用するURLを示します。領収書が同期する場合、このヘッダーは存在しません。RFC 2822アドレスに限定されていたため、気質 - notification-to-to-to-notification-toはこの仕様では使用されません。エクステンションヘッダー「Receide-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
領収書 - 配信オプション：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
領収書 - 配信オプション：https：//www.example.com
An example request for an asynchronous MDN via an SMTP transport:
SMTP輸送を介した非同期MDNの例の例：
Receipt-delivery-option: mailto:as2@example.com
For more information on requesting SMTP MDNs, refer to RFC 3335 [4].
SMTP MDNSを要求する詳細については、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:
最後に、[5]のように、ヘッダーである処分 - 解釈オプションは、メッセージ処分通知の特性を識別します。これらのオプションの中で最も重要なのは、次の例のように、MDNの署名オプションを示すことです。
Disposition-notification-options: signed-receipt-protocol=optional,pkcs7-signature; signed-receipt-micalg=optional,sha1,md5
気質 - 節解決書：signed-receipt-protocol = optional、pkcs7-signature;signed-receipt-micalg = optional、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"
parameter =属性 "="重要 "、" 1＃値 "
where
importance = "required" | "optional"
So the Disposition-notification-options string could be:
したがって、気質 - notification-options文字列は次のとおりです。
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.
<プロトコルシンボル>の現在使用されている値は、S/MIMEデタッチされた署名形式の「PKCS7-Signature」です。
The currently supported values for MIC algorithm <micalg> values are:
マイクアルゴリズム<MICALG>値の現在サポートされている値は次のとおりです。
Algorithm Value Used
--------- -------
SHA-1 sha1
MD5 md5
The semantics of the "signed-receipt-protocol" and the "signed-receipt-micalg" parameters are as follows:
「Signed-Receipt-Protocol」と「Signed-Receipt-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. 「Signed-Receipt-Protocol」パラメーターは、受信者取引パートナーに署名された領収書を要求するために使用されます。「Signed-Receipt-Protocol」パラメーターは、署名された領収書をリクエスターに返送する形式も指定します。
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」パラメーターは、返品された領収書に署名する際に使用するために要求者が好むマイクアルゴリズムのリストです。マイクアルゴリズムのリストは、受信者が左から右に尊重する必要があります。
Both the "signed-receipt-protocol" and the "signed- receipt-micalg" option parameters are REQUIRED when requesting a signed receipt.
署名済みの領収書をリクエストするときに、「署名されたReceipt-Protocol」と「Signed-Receide-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".
「領収書配送」の存在の欠如は、領収書が本質的に同期していることを示しています。「領収書配信オプション：Return-URL」の存在は、非同期領収書が要求され、「Return-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.
「Signed-Receipt-Protocol」パラメーターまたは「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. 領収書が要求された場合、領収書に署名されることを明示的に指定しますが、受信者は要求されたプロトコル形式または要求されたマイクアルゴリズムのいずれかをサポートできません。その後、署名された領収書または署名されていない領収書を返品する必要があります。
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.
注：インターネット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:
署名済みの領収書リクエストが行われると、「受信コンテンツマイク」は常にリクエスターに返される必要があります（破損が次の仕様に従ってダイジェストの計算を防ぐ場合を除く）。「受信コンテンツマイク」は次のように計算する必要があります。
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ヘッダーとコンテンツで計算されます。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ヘッダーとコンテンツで計算されます。復号化後のコンテンツは、マイクが計算される前に正規化する必要があります。
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 署名されていない、暗号化されていないメッセージの場合、MIMEまたは他のRFC 2822ヘッダーなしでメッセージコンテンツを介してマイクを計算する必要があります。
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-SYNC-MDN |AS2-ASYNC-HTTP-MDN |AS2-ASYNC-SMTP-MDN
AS2-sync-MDN = Status-Line *(( general-header | response-header | entity-header ) CRLF ) CRLF AS2-MDN-body
AS2-Sync-Mdn = status-line *（（general-header | response-header | entity-header）crlf）crlf as2-mdn-body
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
Status-Line = HTTP-Version SPステータスコードSP REASON-PHRASE CRLF
AS2-async-http-MDN = Request-Line *(( general-header | request-header | entity-header ) CRLF ) CRLF AS2-MDN-body
AS2-ASYNC-HTTP-MDN = request-line *（（general-header | request-header | entity-header）crlf）crlf as2-mdn-body
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
request-line = method sp request-uri sp http-version crlf
AS2-async-smtp-MDN = *(( general-header | request-header | entity-header ) CRLF ) CRLF AS2-MDN-body
AS2-ASYNC-SMTP-MDN = *（（General-Header | Request-Header | Entity-Header）CRLF）CRLF AS2-MDN-BODY
AS2-MDN-body = AS2-signed-MDN-body | AS2-unsigned-MDN-body
As2-Mdn-body = as2-signed-mdn-body |AS2-UNSIGNED-MDN-BODY
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 of "multipart/report" and parameters indicating the report-type, and the value of the outermost multipart boundary.
AS2-MDN-Bodyは、「処分」のレポートタイプのMIMEマルチパート/レポートとしてフォーマットされています。メッセージが署名されていない場合、AS2-MDNのトランスファーレイヤー（「外側」）エンティティヘッダーには、コンテンツタイプの「マルチパート/レポート」とレポートタイプを示すパラメーターを指定するコンテンツタイプのヘッダーが含まれています。最も外側のマルチパート境界の値。
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のトランスファーレイヤー（「外側の "）エンティティヘッダーには、「MultiPart/Signed」のコンテンツタイプのコンテンツタイプのヘッダーと、使用されるアルゴリズムを示すパラメーターを指定するコンテンツタイプのヘッダーが含まれています。メッセージダイジェスト、署名形式のプロトコル（PKCS7シグネチャなど）、および最も外側のマルチパート境界の値を計算します。Mime MultiPart/署名されたメッセージの最初の部分は、「処分」タイプの埋め込みMIMEマルチパート/レポートです。MultiPart/署名されたメッセージの2番目の部分には、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 MultiPart/レポートの最初の部分は、メッセージ処分の一般的な説明を含む「人間が読める」部分です。Mime MultiPart/レポートの2番目の部分は、次のように定義されている「マシン読み取り可能な」部分です。
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で提供されている気質 - 解釈コンテンツルールと同一です。そして、AS2受信コンテンツマイックフィールドが追加されたこと。RFC 3798処分場とAS2拡散フィールドの違いを以下に説明します。このドキュメントとRFC 3798の間に違いがある場合、これらのエンティティ名は「AS2-」を事前に保留することで変更されました。RFC 3798と違いはないエンティティは、このドキュメントでは必ずしもさらに定義されているわけではありません。元の文法については、RFC 3798、セクション7「収集された文法」を参照してください。
AS2-disposition-field =
"Disposition" ":" disposition-mode ";"
AS2-disposition-type [ '/' AS2-disposition-modifier ]
disposition-mode = action-mode "/" sending-mode
処分モード=アクション - モード "/"送信モード
action-mode =
"manual-action" | "automatic-action"
sending-mode =
"MDN-sent-manually" | "MDN-sent-automatically"
AS2-disposition-type =
"processed" | "failed"
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-Disposition-Modifier-Extension = "Error：Authentication-Failed" |「エラー：減圧症」|「エラー：復号化された」|「エラー：問題のないセキュリティ」|「エラー：Integrity-Check-Failed」|「エラー：予期しない処理エラー」|「警告：」AS2-MDN-Warning-Description |「障害： "AS2-MDN-failure-description
AS2-MDN-warning-description = *( TEXT )
AS2-MDN-failure-description = *( TEXT )
AS2-received-content-MIC-field =
"Received-content-MIC" ":" encoded-message-digest ","
digest-alg-id CRLF
encoded-message-digest =
1*( 'A'-Z' | 'a'-'z' | '0'-'9' | '/' | '+' | '=' ) (
i.e. base64( message-digest ) )
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.
受信したメッセージの整合性が検証されている場合、「受信コンテンツマイク」拡張フィールドが設定されます。マイクは、ハッシュ関数を使用して受信したメッセージを介して計算された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.
署名されたメッセージの場合、マイクの計算に使用されるアルゴリズムは、署名されたメッセージで使用されているものと同じでなければなりません。メッセージに署名されていない場合は、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-disposition-Modifier値、およびユーザーサプライ *（テキスト）値もケースの鈍感です。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トランザクションの場合、元のレシピエントで最終的なレシピエントは違いはありません。Original-Message-IDの値は、元のMessage-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 UAが以前に設定されていたため、MDNが送信されたときに「MDN-Sent-Automatical」の送信モードを使用します。
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-Sent-sent-sent」の送信モードを使用します。
o The sending-mode "MDN-sent-manually" is meaningful ONLY with "manual-action", not with "automatic-action".
o 送信モード「MDN-Sent-hanger」は、「自動アクション」ではなく「手動アクション」でのみ意味があります。
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 「失敗した」処分タイプは、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.
処分モードの2番目の部分は、ユーザーがMDNが送信されるように明示的な許可を与えた場合、「MDN-Sent-sent-sent-manyally」に設定されます。繰り返しますが、送信者が要求したときに、ユーザーが署名された領収書の送信を明示的に拒否することを許可されてはなりません。「処分モード」の2番目の部分は、EDI UAがユーザー、管理者、またはソフトウェアの制御下にあるかどうかにかかわらず、EDI UAがMDNを自動的に送信するたびに「MDN-Sent-Automatical」に設定されます。
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
処分：自動アクション/MDN-Sent-Automatical;処理
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:
署名された領収書のリクエストには、返された署名された領収書のプロトコル形式を指定する2つの「気質 - 解釈オプション」の使用と、メッセージコンテンツ上のマイクを計算するために使用されるマイクアルゴリズムが必要です。メッセージコンテンツが拒否または無視されている場合に使用する必要がある「処分フィールド」値（たとえば、EDI UAが要求されたプロトコル形式をサポートしていないために署名された領収書を返すことができないと判断した場合、EDI UAは選択しますメッセージの内容自体を処理しないでください）次のように、MDN「処分場」で指定する必要があります。
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の適切な生成を防ぐ障害が発生した場合、「故障した」AS2-ディスポジションタイプを使用する必要があります。たとえば、メッセージの送信者がサポートされていないメッセージ-Integrity-Check（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.
「障害：」AS2-Disposition-Modifier-Extensionは、障害の実装定義の説明で使用する必要があります。障害に関する詳細情報は、障害フィールドに含まれる場合があります。
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:
「失敗した」処分型の構文は一般的であり、「失敗した」処分型とともにテキスト情報を送信できます。実装は、失敗の処分タイプの後、印刷可能なテキスト文字をサポートする必要があります。インターネットEDIで使用するには、次の「失敗した」値が事前に定義されており、サポートする必要があります。
"Failure: unsupported format"
「失敗：サポートされていない形式」
"Failure: unsupported MIC-algorithms"
「失敗：サポートされていないマイクアルゴリズム」
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.
「処理された」処分型を使用した「エラー」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-Disposition-Modifier-Extensionを使用して、エラーの表示と特定のよく知られたエラーの事前定義された説明を組み合わせる必要があります。エラーに関する詳細情報は、エラーフィールドに含まれる場合があります。
For internet EDI use, the following "error" AS2-disposition-modifier values are defined:
インターネット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 「エラー：Integrity-Check-Failed」 - 受信者はコンテンツの整合性を検証できませんでした。
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
処分：「処分モード」;処理/エラー：復号化された
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.
EDIでは、取引パートナーを正しく認証できなくても、取引パートナーがEDIトランザクションの処理を継続することに依然として同意した場合に、状況が発生します。取引調整は、後で取引パートナー間で行われます。上記のコンテンツ処理の警告状況では、「処理型」を「処理された」処分型値に、「気質モジュア」値に「警告」を設定する必要があります。
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-Disposition-Modifier-Extensionを使用して、警告の表示と警告の実装定義の説明を組み合わせる必要があります。警告の詳細は、警告場に含まれる場合があります。
For use in Internet EDI, the following "warning" disposition-modifier-extension value is defined:
インターネット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
処分：「処分モード」;処理/警告：認証が除外され、処理が続きました
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実装で使用されている気質フィールドの典型的な構造を表しています。これは、可能な構造の徹底的なリストではありません。ただし、AS2の実装は、このタイプの構造を、以前のAS2バージョンと後方互換性のあるものにする必要があります。
Disposition: automatic-action/MDN-sent-automatically; processed
処分：自動アクション/MDN-Sent-Automatical;処理
Disposition: automatic-action/MDN-sent-automatically; processed/error: authentication-failed
処分：自動アクション/MDN-Sent-Automatical;処理/エラー：認証装備
Disposition: automatic-action/MDN-sent-automatically; processed/warning: duplicate-document
処分：自動アクション/MDN-Sent-Automatical;処理/警告：複製ドキュメント
Disposition: automatic-action/MDN-sent-automatically; failed/failure: sender-equals-receiver
処分：自動アクション/MDN-Sent-Automatical;失敗/失敗：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サーバーは、現時点でオプションのエラー、警告、または障害フィールドを認識または処理する必要はありません。以下の2番目の例で複数のエラーフィールドを使用すると、複数のエラー条件の表示があることに注意してください。
Disposition: automatic-action/MDN-sent-automatically; processed
処分：自動アクション/MDN-Sent-Automatical;処理
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-Sent-Automatical;処理/エラー：復号化されたエラー：署名は、有効な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-Sent-Automatical;処理/警告：重複ドキュメント警告：宛先サーバーには同じメッセージが既に存在します。
Disposition: automatic-action/MDN-sent-automatically; failed/failure: sender-equals-receiver Failure: The AS2-To name is identical to the AS2-From name.
処分：自動アクション/MDN-Sent-Automatical;失敗/障害：送信者-Equals-Receiver障害：AS2-to Nameは、AS2-FR-FR-From Nameと同一です。
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
処分：自動アクション/MDN-Sent-Automatical;処理
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-Sent-Automatical;処理/エラーエラー：認証対応エラー：署名は、有効なPKCS＃1 TYPE-2ブロックに復号化されませんでした。エラー：復号化されたキーの長さは、弾性率のオクテットの長さに等しくありません。
Disposition: automatic-action/MDN-sent-automatically;
processed/warning
Warning: duplicate-document
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.
ポストコマンドへの応答の詳細は、領収書が要求されたかどうかによって異なります。
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と密接に並行します。たとえば、気質フィールドは、MDNのマルチパート/レポートのマシン読み取り可能な第2部で必要な要素です。最終レシピエントフィールド（[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では、MultiPart/レポートの最初の部分（人間読み取り可能な部分）には、件名、日付、およびその他の情報などのアイテムを、POSTリクエストに応じてエンティティヘッダーフィールドにそれらのフィールドが存在する場合は、その他の情報を含める必要があります。アプリケーションは、マルチパート/レポートの第2部（マシン読み取り可能な部分）のリクエストのメッセージ-IDを報告する必要があります。また、MDNには独自のメッセージ-ID HTTPヘッダーが必要です。HTTP返信は、通常、MultiPart/レポートの3番目のオプション部分を省略する必要があります（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, 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.
短期的には、公開鍵の交換とこれらのキーの認証は、取引パートナーシップを確立するプロセスの一環として処理する必要があります。UAおよび/またはEDIアプリケーションインターフェイスは、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].
トレーディングパートナーがS/MIMEを使用している場合、[12]で提供されるアドバイスを考慮して、公開キーの証明書も交換することをお勧めします。
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.
RFC 3851 [7]から抽出：40ビット暗号化は、ほとんどの暗号化者によって弱いと見なされます。S/MIMEで弱い暗号化を使用すると、プレーンテキストの送信に関する実際のセキュリティはほとんどありません。ただし、トリプルDEの仕様や、コミュニケーションをとる当事者により強力な暗号化機能を発表する能力など、S/MIMEの他の機能により、送信者は強力な暗号化を使用するメッセージを作成できます。唯一の代替手段が暗号化されていない場合を除き、弱い暗号化を使用することは決して推奨されません。実行可能な場合、送信および受信エージェントは、送信者と受信者にメッセージの相対的な暗号化強度を通知する必要があります。
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 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.
RFC 3850から抽出[12]：証明書を処理する場合、処理が失敗する可能性のある多くの状況があります。処理はユーザーエージェント、セキュリティゲートウェイ、またはその他のプログラムによって行われる可能性があるため、そのような障害を処理する方法はありません。ただし、障害を処理する方法がリストされていないからといって、読者はそれらが重要ではないと想定すべきではありません。逆の場合は、証明書が有効でなくメッセージに関連付けられていない場合、処理ソフトウェアは、エンドユーザーにそれを通知するために即座に顕著な手順を実行する必要があります。
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.
1つの強力なメカニズムのクラスター（安全な伝送ループ）は、元の送信者による領収書の非和解の証拠的ニーズを満たすことと、すべての記載された証拠が提供された第三者による優れたサポートを提供できます。ただし、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.
一部の分析では、領収書の非和解が、元のメッセージの送信者の非repudiationが取得されていることを前提としており、さらに、元のメッセージにデジタル署名によって非repudiationが実装されるべきであることを観察しています。厳格な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要件の前の分析を満たすために、元のメッセージからデジタル署名が省略されている場合、一部の認証メカニズムは伴う必要があることを認識することが重要です。署名済みの領収書とその含まれた受信コンテンツマイック値のリクエスト。この認証は、クライアント側の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が採用されたポリシーの目標の1つであり、上記の安全な伝送ループのメカニズムを使用して、元のメッセージ送信者サイトで認証の適切な記録を保持することにより、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なしCommon Name属性
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.
ソースサーバーのIDと一致する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は、2つの処分解釈オプションパラメーターを登録しました
Parameter-name: signed-receipt-protocol Parameter-name: signed-receipt-micalg
パラメーター名：signed-receipt-protocol parameter-name：signed-receipt-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
拡張フィールド名：受信-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）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、1996年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、「多目的インターネットメール拡張機能（MIME）パート5：適合基準と例」、RFC 2049、1996年11月。
[2] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, March 1995.
[2] Crocker、D。、「EDIオブジェクトのMIMEカプセル化」、RFC 1767、1995年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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC 2616、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のセキュリティマルチパート：MultiPart/Signed and MultiPart/暗号化」、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。、「Secure/Multipurpose Internet Mail拡張機能（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 Media Types」、RFC 3023、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。、「セキュア/多目的インターネットメール拡張機能（S/MIME）バージョン3.1証明書処理」、RFC 3850、2004年7月。
[13] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[13] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、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.
注：すべての例は、図のみで提供されており、プロトコル仕様の一部とは見なされません。例が、上記または他の参照されたRFCSで指定されたプロトコル定義と競合する場合、例は間違っています。
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コンテンツタイプ：Application/EDI-X12コンテンツ拡散：添付ファイル。filename = rfc1767.dat [isa ... ediトランザクションデータ... iea ...]
--as2BouNdary1as2 Content-Type: application/pkcs7-signature
-as2boundary1as2コンテンツタイプ：Application/PKCS7-Signature
[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
Content-Length: 1980
------=_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--
------=_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--
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をProtocol = "Application/PKCS7-Signature」で準備する方法の詳細については、「S/MIMEメッセージ仕様、MIMEのPKCSセキュリティサービス」を参照してください。）
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. マルチパート/レポートのテキストの最初のボディ部分を使用して、気質ヘッダーによって報告されたエラー条件のより詳細な説明を含めることができることに注意してください。マルチパート/レポートの最初のボディ部分は、この方法で使用されると、人が問題を詳細に診断することができます。
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]で指定されているように、MultiPart/レポートの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
[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
------=_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
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.
メッセージ<x12.edi>は、2002年12月19日15:04:18 gmt <async mdn request>を受信者に受信者<as2テスト>に送信しました。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
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_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=
H0ZPNEQLQBABH29Y2V82B8BDEGW8PIPBQWMF53HICQHGM 4ZBF3CHW5WRF1JIE 8TWOZDBAL30ZECHW88WFRFD7C/J1FIA8 qxfaeecgzguaaaaaaaaa =
------=_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 E. Hartford Drive、Suite 100 Scottsdale、AZ 85255 USA
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. 4700 Bryant Irvin Court、Suite 303 Fort Worth、TX 76107 USA
EMail: rvd2@drummondgroup.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。