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)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document provides an applicability statement (RFC 2026, Section 3.2) that describes how to exchange structured business data securely using the HTTP transfer protocol, instead of SMTP; the applicability statement for SMTP is found in RFC 3335. Structured business data may be XML; Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format; or other structured data formats. The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts. Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. This applicability statement is informally referred to as "AS2" because it is the second applicability statement, produced after "AS1", RFC 3335.
この文書ではなくSMTPのHTTP転送プロトコルを使用して、しっかりと構造化された業務データを交換する方法について説明適用性声明（RFC 2026、セクション3.2）を提供します。 SMTPのための適用性の文がXMLかもしれRFC 3335構造化ビジネスデータに発見されました。どちらかのアメリカ規格委員会（ANSI）X12形式の電子データ交換（EDI）や管理のための国連の電子データ交換、商業、交通（UN / EDIFACT）フォーマット。または他の構造化データ形式。データは、標準のMIME構造を使用してパッケージ化されています。認証およびデータの機密性は、S / MIMEセキュリティ本体部分と暗号メッセージ構文を使用することによって得られます。認証された肯定応答は、元のHTTPメッセージにマルチパート/署名されたメッセージ気質通知（MDN）応答を利用します。それは、RFC 3335「AS1」の後に生成された第2の適用文は、あるため、この適用性声明は非公式に「AS2」と呼ばれています。
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の前の仕事は、[4] [2] EDIデータのMIMEコンテンツタイプを指定することに注力し、SMTPを介してセキュアなEC / EDIトランスポートをサポートするために、この作業を拡張します。このドキュメントでは、データセキュリティ機能、特にデータの機密性、データの整合性/信頼性、起源の否認防止、およびHTTP経由で受領の否認防止の包括的なセットを指定するには、RFC 1767を拡張したものです。また、このドキュメントでは、現代的な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
RFC 3798のメッセージ処分通知OのRFC 3851、3852 O 2049のMIMEのRFCにRFC 2045〇〇RFC 2616ハイパーテキスト転送プロトコルOのRFC 1767 EDIコンテンツO型RFC MIME 0のRFC 3462マルチパート/レポートのためのRFC 1847個のセキュリティマルチパートO 3023のXMLメディアタイプ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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [13]に記載されているように解釈されます。
AS2: Applicability Statement 2 (this document); see RFC 2026 [11], Section 3.2
AS2：適用ステートメント2（本書）。 RFC 2026 [11]、3.2節を参照してください
EDI: Electronic Data Interchange
ただし、電子データintercange
EC: Business-to-Business Electronic Commerce
EC：企業間電子商取引
B2B: Business to Business
B2B：企業間取引
Receipt: The functional message that is sent from a receiver to a sender to acknowledge receipt of an EDI/EC interchange. This message may be either synchronous or asynchronous in nature.
レシート：EDI / EC交換の受信を確認するために送信側に受信機から送信されるメッセージ機能。このメッセージは、本質的に、同期または非同期のいずれであってもよいです。
Signed Receipt: A receipt with a digital signature.
署名された領収書：デジタル署名付き領収書。
Synchronous Receipt: A receipt returned to the sender during the same HTTP session as the sender's original message.
同期領収書：領収書は、送信者の元のメッセージと同じHTTPセッション中に送信者に返さ。
Asynchronous Receipt: A receipt returned to the sender on a different communication session than the sender's original message session.
非同期領収書：領収書は、送信者の元のメッセージセッションとは異なる通信セッションに送信者に返さ。
Message Disposition Notification (MDN): The Internet messaging format used to convey a receipt. This term is used interchangeably with receipt. A MDN is a receipt.
メッセージ気質通知（MDN）：領収書を伝えるために使用されるインターネットメッセージング形式。この用語は、領収書と交換可能に使用されます。 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）は、また、メッセージダイジェストと呼ばれ、デジタル署名が使用するハッシュアルゴリズムのダイジェストが出力されます。デジタル署名は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.
[3]のHTTP POST動作を適切に包装EDI、XML、または他のビジネスデータを送信するために使用されます。 Request-URIが（[3]、セクション9.5）をアンパックし、メッセージデータを処理するための符号付きまたは符号なしのいずれかで、メッセージの配置確認（MDN）を含むクライアントに対する応答を生成するためのプロセスを識別する。 MDNは、いずれかの元の送信者のためのURLにHTTP応答メッセージの本文に、または新しい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のための「安全な送信ループ」では、一つの組織が別の組織に署名し、暗号化された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.
EDI / ECのデータサインを送っ組織OおよびS / MIMEを使用してデータを暗号化します。加えて、メッセージは、署名された領収書が送信者に返されることを要求します。 NRRをサポートするために、元の送信者は、メッセージ、メッセージIDのレコードを保持し、（MIC）値をダイジェスト。
o The receiving organization decrypts the message and verifies the signature, resulting in verified integrity of the data and authenticity of the sender.
O受信組織は、メッセージを復号化し、データと送信者の真正性の検証完全性をもたらす、署名を検証します。
o The receiving organization then returns a signed receipt using the HTTP reply body or a separate HTTP POST operation to the sending organization in the form of a signed message disposition notification. This signed receipt will contain the hash of the received message, allowing the original sender to have evidence that the received message was authenticated and/or decrypted properly by the receiver.
O受信組織は、その後、HTTP応答の本体または署名されたメッセージ気質通知の形で送信組織に別個のHTTP POSTオペレーションを使用して署名された領収書を返します。この署名された領収書は、元の送信者が、受信したメッセージが認証および/または受信機によって正しく復号化されたという証拠を有することができるように、受信したメッセージのハッシュを含むことになります。
The above describes functionality that, if implemented, will satisfy all security requirements and implement non-repudiation of receipt for the exchange. This specification, however, leaves full flexibility for users to decide the degree to which they want to deploy those security features with their trading partners.
上記は、実装されている場合、すべてのセキュリティ要件を満たし、交換のための領収書の否認防止を実装する機能について説明します。この仕様は、しかし、彼らは彼らの貿易相手国で、これらのセキュリティ機能を展開するための程度を決定するユーザーのための完全な柔軟性を残します。
The term used for both the functional activity and the message for acknowledging delivery of an EDI/EC interchange is "receipt" or "signed receipt". The first term is used if the acknowledgment is for an interchange resulting in a receipt that is NOT signed. The second term is used if the acknowledgement is for an interchange resulting in a receipt that IS signed.
機能活性およびEDI / EC交換の配信に応答するためのメッセージの両方のために使用される用語は、「領収書」または「署名された領収書」です。肯定応答が署名されていない領収書をもたらす交換のためのものである場合は、最初の用語が使用されます。肯定応答が署名されている領収書をもたらす交換のためのものである場合に、第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.
領収書の用語否認防止（NRR）は、多くの場合、領収書と組み合わせて使用されます。 NRRは交換の元の送信者がメッセージの受信者から戻ってくる署名された領収書を検証しており、MDN内部返さMIC値は、元のメッセージのために以前に記録された値と一致することを確認した場合にのみ発生法的イベントを指します。
NRR is best established when both the original message and the receipt make use of digital signatures. See the Security Considerations section for some cautions regarding NRR.
元のメッセージと受信の両方がデジタル署名を利用する際NRRが最高の確立されています。 NRRに関するいくつかの注意事項についてはセキュリティの考慮事項のセクションを参照してください。
For information on how to format and process receipts in AS2, refer to Section 7.
AS2に領収書をフォーマットし、処理する方法については、セクション7を参照してください。
o Encrypted object is an EDI/EC Interchange.
O暗号化されたオブジェクトは、EDI / EC交換です。
This specification assumes that a typical EDI/EC interchange is the lowest-level object that will be subject to security services.
この仕様は、典型的なEDI / EC交換は、セキュリティサービスの対象となる最低レベルのオブジェクトであると仮定しています。
Specifically, in EDI ANSI X12, this means that anything between and including, segments ISA and IEA is secured. In EDIFACT, this means that anything between, and including, segments UNA/UNB and UNZ is secured. In other words, the EDI/EC interchanges including envelope segments remain intact and unreadable during fully secured transport.
具体的には、EDI ANSI X12に、これは何の間などは、セグメントISAおよびIEAが確保されることを意味します。 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.
インターネットに（付加価値通信網またはのVANと呼ばれる）は、既存の商用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はEDIFACTのセキュリティを提供します。この仕様は、これらのセキュリティ標準の使用または不使用を規定していません。これらは、本明細書で、両方しかしおそらく冗長、完全に互換性があります。
o Encrypted or Unencrypted Data
O暗号化または暗号化されていないデータ
This specification allows for EDI/EC message exchange in which the EDI/EC data can be either unprotected or protected by means of encryption.
この仕様は、EDI / ECデータが保護されていないか、暗号化によって保護されたいずれかの可能なEDI / ECのメッセージ交換を可能にします。
o Signed or Unsigned Data
O付きまたは符号なしデータ
This specification allows for EDI/EC message exchange with or without digital signature of the original EDI transmission.
この仕様は伴うまたは元のEDI送信のデジタル署名なしのEDI / ECのメッセージ交換を可能にします。
o Optional Use of Receipt
領収書の任意の使用O
This specification allows for EDI/EC message transmission with or without a request for receipt notification. A signed receipt notification is requested; however, a MIC value is REQUIRED as part of the returned receipt, except when a severe error condition prevents computation of the digest value. In the exceptional case, a signed receipt should be returned with an error message that effectively explains why the MIC is absent.
この仕様は、または受領通知の要求なしEDI / ECのメッセージ送信を可能にします。署名された受領通知が要求されています。しかしながら、MIC値は、重大なエラー状態がダイジェスト値の計算を妨げる場合を除いて、返された領収書の一部として必要とされます。例外的な場合には、署名された領収書は、MICが存在しない理由を効果的に説明するエラーメッセージと共に返されるべきです。
o Use of Synchronous or Asynchronous Receipts
同期または非同期領収書のOを使用
In addition to a receipt request, this specification allows the specification of the type of receipt that should be returned. It supports synchronous or asynchronous receipts in the MDN format specified in Section 7 of this document.
受信要求に加えて、本明細書に返されるべきレシートの種類の指定を可能にします。これは、このドキュメントのセクション7で指定されたMDN形式で同期または非同期の領収書をサポートしています。
o Security Formatting
Oセキュリティのフォーマット
This specification relies on the guidelines set forth in RFC 3851/3852 [7] "S/MIME Version 3.1 Message Specification; Cryptographic Message Syntax".
この仕様はRFC 3852分の3851に定められたガイドラインに依存している[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マルチパートのセキュリティを定義します。
This RFC defines the use of the multipart/report content type, something that the MDN RFC 3798 builds upon.
このRFCは、マルチパート/レポートのコンテンツタイプ、MDNのRFC 3798が上に構築何かの使用を定義します。
This RFC defines the use of content type "application" for ANSI X12 (application/EDI-X12), EDIFACT (application/EDIFACT), and mutually defined EDI (application/EDI-Consent).
このRFCは、ANSI X12（アプリケーション/ EDI-X12）、EDIFACT（アプリケーション/ EDIFACT）、および相互定義EDI（アプリケーション/ EDI-同意）のコンテンツタイプ "アプリケーション" の使用を定義します。
These are the basic MIME standards, upon which all MIME related RFCs build, including this one. Key contributions include definitions of "content type", "sub-type", and "multipart", as well as encoding guidelines, which establish 7-bit US-ASCII as the canonical character set to be used in Internet messaging.
これらはすべて、MIME関連のRFCはこの1つを含む、構築、その上に基本的な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は領収書と署名された領収書は、本明細書で定義されてその上に基礎です。
3.7. and 3852 S/MIME Version 3.1 Message Specifications and Cryptographic Message Syntax (CMS) []
3.7. そして3852 S / MIMEバージョン3.1メッセージ仕様および暗号メッセージ構文（CMS）[]
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のコンテンツタイプ「アプリケーション」（アプリケーション/ 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メッセージの基本構造は、いくつかの追加特定AS2ヘッダーとHTTPメッセージ内のMIME形式で構成されています。以下の構造は、RFCは特定の構造を形成するために適用されるという点で階層的に記載されています。関係するすべてのRFCに準拠したコーディングする方法の詳細については、参照先のRFCに直接向けます。 AS2注入およびRFCとの間の差は、具体的に以下のセクションに記載されています。
No encryption, no signature -RFC2616/2045 -RFC1767/RFC3023 (application/EDIxxxx or /xml)
暗号化なし、無署名/ 2045 -RFC2616 -RFC1767 / RFC3023（アプリケーション/ EDIxxxx又は/ XML）
No encryption, signature -RFC2616/2045 -RFC1847 (multipart/signed) -RFC1767/RFC3023 (application/EDIxxxx or /xml) -RFC3851 (application/pkcs7-signature)
何の暗号化、署名-RFC2616 / 2045 -RFC1847（マルチパート/署名された）-RFC1767 / RFC3023（アプリケーションない/ EDIxxxx又は/ XML）-RFC3851（アプリケーション/ PKCS7署名）
Encryption, no signature -RFC2616/2045 -RFC3851 (application/pkcs7-mime) -RFC1767/RFC3023 (application/EDIxxxx or /xml)(encrypted)
暗号化、無署名-RFC2616 / 2045 -RFC3851（アプリケーション/ PKCS7-MIME）-RFC1767 / RFC3023（アプリケーション/ EDIxxxx又は/ XML）（暗号化）
Encryption, signature -RFC2616/2045 -RFC3851 (application/pkcs7-mime) -RFC1847 (multipart/signed)(encrypted) -RFC1767/RFC3023 (application/EDIxxxx or /xml)(encrypted) -RFC3851 (application/pkcs7-signature)(encrypted)
暗号化、署名-RFC2616 / 2045 -RFC3851（アプリケーション/ PKCS7-MIME）-RFC1847（マルチパート/署名された）（暗号化）-RFC1767 / RFC3023（/ EDIxxxx又は/ XMLアプリケーション）（暗号化）-RFC3851（アプリケーション/ PKCS7署名） （暗号化）
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（マルチパート/署名された）-RFC3798（メッセージ/気質通知）-RFC3851（アプリケーション/ PKCS7署名）
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
コンテンツタイプ：アプリケーション/ EDIFACTのContent-Type：アプリケーション/ EDI-同意のContent-Type：アプリケーション/ XML
The request line will have the form: "POST Request-URI HTTP/1.1", with spaces and followed by a CRLF. The Request URI is typically exchanged out of band, as part of setting up a bilateral trading partner agreement. Applications SHOULD be prepared to deal with an initial reply containing a status indicating a need for authentication of the usual types used for authorizing access to the Request-URI ([3], Section 10.4.2 and elsewhere).
スペースで、「POSTリクエスト-URIのHTTP / 1.1」とCRLFが続く：リクエスト行の形式を持っています。リクエストURIは、一般的に二国間の貿易相手国の合意を設定するの一環として、帯域外で交換されます。アプリケーションは、Request-URI（[3]、セクション10.4.2および他の場所）へのアクセスを許可するために使用される通常のタイプの認証のための必要性を示す状態を含む初期応答に対処するために準備されるべきです。
The request line is followed by entity headers specifying content length ([3], Section 14.14) and content type ([3], Section 14.18). The Host request header ([3], Sections 9 and 14.23) is also included.
要求ラインは、コンテンツの長さ（[3]、セクション14.14）及びコンテンツタイプ（[3]、セクション14.18）を指定するエンティティヘッダが続きます。ホスト要求ヘッダー（[3]、セクション9及び14.23）も含まれます。
When using Transport Layer Security [15] or SSLv3, the request-URI SHOULD indicate the appropriate scheme value, HTTPS. Usually only a multipart/signed message body would be sent using TLS, as encrypted message bodies would be redundant. However, encrypted message bodies are not prohibited.
トランスポート層セキュリティ[15]またはのSSLv3を使用する場合は、リクエストURIは、適切なスキーム値、HTTPSを示すべきです。通常はマルチパート/署名されたメッセージ本体は、暗号化されたメッセージ本文は、冗長であるように、TLSを使用して送信されることになります。ただし、暗号化されたメッセージ本文は禁止されていません。
The receiving AS2 system MAY disconnect from the sending AS2 system before completing the reception of the entire entity if it determines that the entity being sent is too large to process.
受信AS2システムは、それが送信されるエンティティが処理するには大きすぎると判断した場合に全体エンティティの受信を完了する前に送信AS2システムから切断してもよいです。
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）、デフォルトです。 SMTP輸送に使用されるHTTPは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.
Content-Lengthヘッダの使用は、[3]、具体的にはセクション4.4と14.13のガイドラインに従わなければなりません。
The final and original recipient values SHOULD be the same value. These values MUST NOT be aliases or mailing lists.
最終的な元の受信者の値が同じ値であるべきです。これらの値は、エイリアスやメーリングリストにすることはできません。
Message-Id and Original-Message-Id is formatted as defined in RFC 2822 [9]:
メッセージIDとオリジナル・メッセージID RFC 2822で定義されるようにフォーマットされている[9]。
"<" id-left "@" id-right ">" (RFC 2822, 3.6.4)
"<" ID-右 "@" ID-左 ">"（RFC 2822、3.6.4）
Message-Id length is a maximum of 998 characters. For maximum backward compatibility, Message-Id length SHOULD be 255 characters or less. Message-Id SHOULD be globally unique, and id-right SHOULD be something unique to the sending host environment (e.g., a host name).
メッセージIDの長さは998文字の最大です。最大の後方互換性のために、メッセージIDの長さは255文字以下としてください。メッセージIDは、グローバルに一意でなければならず、ID-右は送信ホスト環境（例えば、ホスト名）にユニークなものであるべきです。
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で原稿のMessage-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ヘッダと、Authorizationヘッダで要求を繰り返すクライアントに挑戦するために使用されます。他の明示的なステータスコードは、[3]、セクション6.1.1及びセクション10全体に記載されています。
For errors in the request-URI, 400 ("Bad Request"), 404 ("Not Found"), and similar codes are appropriate status codes. These codes and their semantics are specified by [3]. A careful examination of these codes and their semantics should be made before implementing any retry functionality. Retries SHOULD NOT be made if the error is not transient or if retries are explicitly discouraged.
リクエストURIのエラーについては、400（「無効な要求」）、404（「見つかりません」）、および同様のコードは、適切なステータスコードです。これらのコードとその意味は[3]で指定されています。これらのコードとその意味の慎重な検査は任意の再試行機能を実装する前になされるべきです。エラーが一時的でない場合、または再試行が明示的に推奨された場合の再試行を行うべきではありません。
If the HTTP client fails to read the HTTP server response data, the POST operation with identical content, including same Message-ID, SHOULD be repeated, if the condition is transient.
HTTPクライアントは、HTTPサーバの応答データの読み取りに失敗した場合は条件が一時的である場合、同じMessage-IDを含む同一の内容とPOST操作は、繰り返されるべきです。
The Message-ID on a POST operation can be reused if and only if all of the content (including the original Date) is identical.
メッセージID POSTオペレーションには、（元の日付を含む）コンテンツのすべてが同一である場合にのみ再利用することができます。
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.
サーバーは繰り返しのMessage-IDを持つPOSTを受け取るように準備されるべきです。以前に送信されたMIME応答体はMDNおよび他のMIME部分を含む、再送信されるべきです。
The following headers are to be included in all AS2 messages and all AS2 MDNs, except for asynchronous MDNs that are sent using SMTP and that follow the AS1 semantics[4].
[4]以下のヘッダはSMTPを使用して送信された非同期開封通知を除いて、すべてのAS2メッセージとすべてのAS2の開封通知に含まれるべきであり、それは、AS1セマンティクスに従います。
To promote backward compatibility, AS2 includes a version header:
後方互換性を促進するために、AS2は、バージョンヘッダを含みます。
AS2-Version: 1.0 - Used in all implementations of this specification. 1.x will be interpreted as 1.0 by all implementations with the "AS2 Version: 1.0" header. That is, only the most significant digit is used as the version identifier for those not implementing additional non-AS2-specified functionality. "AS2-Version: 1.0 through 1.9" MAY be used. All implementations MUST interpret "1.0 through 1.9" as implementing this specification. However, an implementation MAY extend this specification with additional functionality by specifying versions 1.1 through 1.9. If this mechanism is used, the additional functionality MUST be completely transparent to implementations with the "AS2-Version: 1.0" designation.
AS2 - バージョン：1.0 - この仕様のすべての実装に使用されます。ヘッダ：1.1「が1.0 AS2バージョン」を持つすべての実装によって1.0と解釈されるであろう。それは、唯一の最上位の桁は、追加の非AS2-指定された機能を実装していない人のためバージョン識別子として使用されています。 "AS2-バージョン：1.9 1.0〜" は使用されるかもしれません。すべての実装は、この仕様を実装すると、「1.9を通じて1.0」を解釈する必要があります。しかし、実装がバージョン1.9を介して1.1を指定することによって、追加の機能を、本明細書を延長することができます。名称：このメカニズムを使用する場合、追加機能は、「1.0 AS2 - バージョン」との実装に完全に透明でなければなりません。
AS2-Version: 1.1 - Designates those implementations that support compression as defined by RFC 3274.
AS2 - バージョン：1.1 - RFC 3274で定義されている圧縮をサポートする実装を指定します。
Receiving systems MUST NOT fail due to the absence of the AS2-Version header. Its absence would indicate that the message is from an implementation based on a previous version of this specification.
受信システムが原因AS2 - バージョンヘッダが存在しないために失敗してはなりません。その不在は、メッセージがこの明細書の前のバージョンに基づいて実装からのものであることを示すであろう。
To aid the receiving system in identifying the sending system, AS2-From and AS2-To headers are used.
送信システムを識別する受信システムを助けるために、AS2-FromとAS2-TOヘッダーが使用されています。
AS2-From: < AS2-name >
AS2-To: < AS2-name >
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-テキスト= "！" /;印刷可能なASCII文字％d35-91 /。二重引用符（％D34）％のd93-126除きます。またはバックスラッシュ（％のD92）
AS2-qtext = AS2-text / SP ; allow space only in quoted text
AS2-qtext = AS2-テキスト/ SP;だけ引用されたテキストにスペースを許可します
AS2-quoted-pair = "\" DQUOTE / ; \" or "\" "\" ; \\
AS2引用符で囲まれたペア=「\」DQUOTE /。 \" または "\" "\" ; \\
AS2-quoted-name = DQUOTE 1*128( AS2-qtext / AS2-quoted-pair) DQUOTE
AS2引用名= DQUOTE 1×128（AS2-qtext / AS2-引用対）DQUOTE
AS2-atomic-name = 1*128AS2-text
AS2-アトミック名= 1 * 128AS2テキスト
AS2-name = AS2-atomic-name / AS2-quoted-name
AS2名= AS2-原子名/ AS2引用符で囲まれた名
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-及びAS2-に値をヘッダ各々がAS2-名前でなければなりませんが、それぞれが1〜128の印刷可能なASCII文字から構成されなければなりません、そして折り畳まれてはいけません。これらのヘッダーのそれぞれの値は、大文字と小文字が区別されます。上記指定された文字列の定義はABNF形式[14]です。
The AS2-quoted-name SHOULD be used only if the AS2-name does not conform to AS2-atomic-name.
AS2引用符で囲まれた名は、AS2-nameはAS2-アトミック名に準拠していない場合にのみ使用されるべきです。
The AS2-To and AS2-From header fields MUST be present in all AS2 messages and AS2 MDNs whether asynchronous or synchronous in nature, except for asynchronous MDNs, which are sent using SMTP.
AS2、およびAS2-からヘッダフィールドは、SMTPを使用して送信された非同期開封通知を除いて、すべてのAS2メッセージとAS2の開封通知本質的に非同期または同期するかどうかに存在していなければなりません。
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.
AS2-に応答またはMDNにヘッダーのAS2-nameは、AS2-からヘッダ対応する要求メッセージ内のAS2名と一致しなければなりません。同様に、AS2-からヘッダ応答またはMDNにするためのAS2-nameは、AS2、AS2に対応する要求メッセージのヘッダーのAS2名と一致しなければなりません。
The sending system may choose to limit the possible AS2-To/AS2-From textual values but MUST not exceed them. The receiving system MUST make no restrictions on the textual values and SHOULD handle all possible implementations. However, implementers must be aware that older AS2 products may not adhere to this convention. Trading partner agreements should be made to ensure that older products can support the system identifiers that are used.
送信側システムは、可能なAS2-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.
値ToヘッダーAS2-無効または不明からAS2-かを含むクライアント要求への対処方法はありません。送信側システムは、MDNを要求した場合に受信AS2システムは、エラーの説明と符号なしのMDNを返す場合があります。
In order to support non-repudiation of receipt, a signed receipt, based on digitally signing a message disposition notification, is to be implemented by a receiving trading partner's UA. The message disposition notification, specified by RFC 3798, is digitally signed by a receiving trading partner as part of a multipart/signed MIME message.
領収書の否認防止をサポートするために、デジタルメッセージ気質通知を署名に基づく署名領収書は、受信した取引相手のUAによって実装されます。 RFC 3798で指定されたメッセージ気質通知は、デジタルマルチパート/署名されたMIMEメッセージの一部として受信取引相手によって署名されます。
The following support for signed receipts is REQUIRED:
署名領収書については、以下のサポートが必要です。
1. The ability to create a multipart/report; where the report-type = disposition-notification.
1.マルチパート/レポートを作成する機能を、どこ報告型=気質通知。
2. The ability to calculate a message integrity check (MIC) on the received message. The calculated MIC value will be returned to the sender of the message inside the signed receipt.
2.受信したメッセージにメッセージ完全性チェック（MIC）を計算する能力。計算されたMIC値は、署名された領収書の内部メッセージの送信者に返されます。
3. The ability to create a multipart/signed content with the message disposition notification as the first body part, and the signature as the second body part.
前記第1のボディ部分としてメッセージ気質通知、及び第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.
送信されたEDI / EC交換が暗号化されている場合は1、その後、暗号化された対称鍵と初期化ベクトルは（該当する場合）、受信者の秘密鍵を使って復号化されます。
2. The decrypted symmetric encryption key is then used to decrypt the EDI/EC Interchange.
2.復号化された対称暗号化キーは、EDI / EC交換を解読するために使用されます。
3. The receiving trading partner authenticates signatures in a message using the sender's public key. The authentication algorithm performs the following:
3.受信貿易相手国は、送信者の公開鍵を使ってメッセージに署名を認証します。認証アルゴリズムは、次のことを実行します。
a. The message integrity check (MIC or Message Digest), is decrypted using the sender's public key.
A。メッセージ完全性チェック（MICまたはメッセージダイジェスト）は、送信者の公開鍵を使って復号化されます。
b. A MIC on the signed contents (the MIME header and encoded EDI object, as per RFC 1767) in the message received is calculated using the same one-way hash function that the sending trading partner used.
B。受信メッセージ内の（RFC 1767あたりとしてMIMEヘッダと符号化されたEDIオブジェクト）署名されたコンテンツに対するMICは、送信取引相手が使用したのと同じ一方向ハッシュ関数を用いて計算されます。
c. The MIC extracted from the message that was sent and the MIC calculated using the same one-way hash function that the sending trading partner used are compared for equality.
C。送信されたメッセージと使用送る貿易相手国が等しいかどうかを比較されるのと同じ一方向ハッシュ関数を用いて計算さMICから抽出したMIC。
4. The receiving trading partner formats the MDN and sets the calculated MIC into the "Received-content-MIC" extension field.
4.受信貿易相手国は、MDNをフォーマットし、「受信コンテンツ-MIC」拡張フィールドに計算されたMICを設定します。
5. The receiving trading partner creates a multipart/signed MIME message according to RFC 1847.
5.受信取引相手は、RFC 1847に従ってマルチパート/署名されたMIMEメッセージを作成します。
6. The MDN is the first part of the multipart/signed message, and the digital signature is created over this MDN, including its MIME headers.
6. MDNは、マルチパート/署名されたメッセージの最初の部分で、デジタル署名は、その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.マルチパート/署名されたメッセージの第2の部分は、デジタル署名を含んでいます。次のようにマルチパート/署名された第二の部分に指定された「プロトコル」オプションがあります。
S/MIME: protocol = "application/pkcs-7-signature"
S / MIME：プロトコル= "アプリケーション/ PKCS-7シグネチャー"
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コンテンツタイプの一部である場合、MICはMIMEヘッダを含む、全体のマルチパートコンテンツを横切って計算しなければなりません。
The signed MDN, when received by the sender of the EDI Interchange, can be used by the sender as follows:
次のようにEDI交換の送信者によって受信された署名されたMDNは、送信者が使用することができます。
o As an acknowledgement that the EDI Interchange sent was
delivered and acknowledged by the receiving trading partner.
The receiver does this by returning the original-message-id
of the sent message in the MDN portion of the signed receipt.
o 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.
EDI交換の整合性は、受信貿易相手国によって検証されたことを確認として、O。受信機は、署名されたMDNの「受信コンテンツMIC」フィールドで受信されたECインターチェンジ（および1767のMIMEヘッダ）の計算されたMICを返すことによってこれを行います。
o As an acknowledgement that the receiving trading partner has authenticated the sender of the EDI Interchange.
受信貿易相手国は、EDI交換の送信者を認証したことを確認として、O。
o As a non-repudiation of receipt when the signed MDN is successfully verified by the sender with the receiving trading partner's public key and the returned MIC value inside the MDN is the same as the digest of the original message.
O署名MDNが正常に受信貿易相手の公開鍵とMDN内部返されたMIC値と送信者によって確認された領収書の否認防止として、元のメッセージのダイジェストと同じです。
The AS2-MDN exists in two varieties: synchronous and asynchronous.
同期および非同期：AS2-MDNは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またはHTTPS POSTにHTTPS応答としてHTTPレスポンスとして送信されます。 AS2-MDNが同じTCP / IP接続上でPOSTの元に返されるため、AS2-MDNのこの形式は、同期と呼ばれています。
The asynchronous AS2-MDN is sent on a separate HTTP, HTTPS, or SMTP TCP/IP connection. Logically, the asynchronous AS2-MDN is a response to an AS2 message. However, at the transfer-protocol layer, assuming that no HTTP pipelining is utilized, the asynchronous AS2-MDN is delivered on a unique TCP/IP connection, distinct from that used to deliver the original AS2 message. When handling an asynchronous request, the HTTP response MUST be sent back before the MDN is processed and sent on the separate connection.
非同期AS2-MDNは、別のHTTP、HTTPS、またはSMTP TCP / IP接続で送信されます。論理的に、非同期AS2-MDNがAS2メッセージに対する応答です。しかし、転送プロトコル層で、全くHTTPパイプラインが利用されていないと仮定すると、非同期AS2-MDNは、元の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-MDNがAS2メッセージの送信者によって要求された場合、同期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メッセージの送信者を提供できることです。メッセージが比較的大きい場合は、このメッセージを処理し、同じTCP / IP接続上で送信者にAS2-MDNを返すために必要な時間は、IP接続のための許容される最大設定された時間を超えてもよいです。
The advantage of the asynchronous MDN is that it provides for the rapid return of a transfer-layer response from the receiver, confirming the receipt of data, therefore not requiring that a TCP/IP connection necessarily remain open for very long. However, this design requires that the asynchronous AS2-MDN contain enough information to identify the original message uniquely so that, when received by the AS2 Message originator, the status of the original AS2 Message can be properly updated based on the contents of the AS2-MDN.
非同期MDNの利点は、従ってTCP / IP接続は、必ずしも非常に長い間開いたままであることを必要とせず、データの受信を確認し、受信機からの転写層の応答の迅速なリターンを提供することです。しかしながら、この設計は、非同期AS2-MDNを一意になるように、元のメッセージを識別するための十分な情報を含むAS2メッセージ発信元によって受信された場合、元のAS2メッセージのステータスが正常AS2-の内容に基づいて更新することができることを必要としますMDN。
Synchronous or asynchronous HTTP or HTTPS MDNs are handled according to the requirements of this specification.
同期または非同期HTTPまたはHTTPS開封通知は、この仕様の要件に従って処理されます。
However, SMTP MDNs are formatted according to the requirements of RFC 3335 [4].
しかし、SMTP開封通知は、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
The following example is for requesting an MDN:
次の例では、MDNを要求するものです。
Disposition-notification-to: xxx@example.com
処分通知-へ：xxx@example.com
This syntax is a residue of the use of MDNs using SMTP transfer. Because this specification is adjusting the functionality from SMTP to HTTP while retaining as much as possible from the [4] functionality, the mail-address MUST be present. The mail-address field is specified as an RFC 2822 localpart@domain [addr-spec] address. However, the address is not used to identify where to return the MDN. Receiving applications MUST ignore the value and MUST not complain about RFC 2822 address syntax violations.
この構文は、SMTP転送を使用して開封通知の使用の残基です。 [4]機能からできるだけ多くを保持しながら本明細書は、HTTPのSMTPの機能を調整しているので、メールアドレスが存在しなければなりません。メールアドレスフィールドは、RFC 2822ローカル部分@ドメイン[addrの指定]アドレスとして指定されています。しかし、アドレスはMDNを返すために、場所を特定するために使用されていません。受信アプリケーションは値を無視しなければなりませんし、RFC 2822アドレス構文違反文句ないしなければなりません。
When requesting MDN-based receipts, the originator supplies additional extension headers that precede the message body. These header "tags" are as follows:
MDNベースのレシートを要求する場合、発信者はメッセージ本文の前に追加の拡張ヘッダを供給する。これらのヘッダーの「タグ」以下のとおりです。
A Message-ID header is added to support message reconciliation, so that an Original-Message-Id value can be returned in the body part of MDN. Other headers, especially "Subject" and "Date", SHOULD be supplied; the values of these headers are often mentioned in the human-readable section of a MDN to aid in identifying the original message.
オリジナル・メッセージ-ID値は、MDNの本体部に戻すことができるように、メッセージ-IDヘッダは、メッセージ更新をサポートするために追加されます。他のヘッダ、特に「件名」と「日」とは、供給されるべきです。これらのヘッダーの値は、多くの場合、元のメッセージを識別するのを助けるためにMDNの人間可読セクションに記載されています。
MDNs will be returned in the HTTP response when requested, unless an asynchronous return is requested.
要求されたときに、非同期復帰が要求されない限り、開封通知は、HTTP応答で返されます。
To request an asynchronous message disposition notification, the following header is placed into the message that is sent:
非同期メッセージ気質通知を要求するために、次のヘッダが送信されたメッセージの中に配置されています。
Receipt-Delivery-Option: return-URL
領収書配信 - オプション：リターン-URL
Here is an example requesting that the MDN be asynchronous:
ここではMDNが非同期であることを要求例です。
Receipt-Delivery-Option: http://www.example.com/Path
領収書配信 - オプション：http://www.example.com/Path
Receipt-delivery-option syntax allows return-url to use some schemes other than HTTP using the POST method.
領収書・デリバリー・オプションの構文は、復帰URLをPOSTメソッドを使用してHTTP以外のいくつかの方式を使用することができます。
The "receipt-delivery-option: return-url" string indicates the URL to use for an asynchronous MDN. This header is NOT present if the receipt is to be synchronous. The email value in Disposition-notification-to is not used in this specification because it was limited to RFC 2822 addresses; the extension header "Receipt-delivery-option" has been introduced to provide a URL for the MDN return by several transfer options.
「領収書配送オプション：リターン-urlは」文字列は、非同期MDNに使用するURLを示します。領収書が同期される場合、このヘッダが存在しません。それはRFC 2822のアドレスに制限されたため、処分通知-にで電子メールの値は、この仕様では使用されません。拡張ヘッダー「領収書・デリバリー・オプションは、」いくつかの転送オプションで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
領収書・デリバリー・オプション：のmailto：as2@example.com
For more information on requesting SMTP MDNs, refer to RFC 3335 [4].
SMTP開封通知を要求する方法の詳細については、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
For signing options, consider the disposition-notification-options syntax:
署名オプションについては、処分通知・オプションの構文を検討してください。
Disposition-notification-options =
"Disposition-Notification-Options" ":"
disposition-notification-parameters
where disposition-notification-parameters = parameter *(";" parameter)
ここで、配置通知パラメータ=パラメータ*（「;」パラメータ）
where parameter = attribute "=" importance ", " 1#value"
パラメータ=属性「=」重要」、 『1つの＃値』
where importance = "required" | "optional"
どこ重要=「必須」| 「オプション」
So the Disposition-notification-options string could be:
だから、処分通知 - オプション文字列は次のようになります。
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署名」です。
The currently supported values for MIC algorithm <micalg> values are:
MICアルゴリズムの現在サポートされている値は、<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:
次のように「署名されたレシート・プロトコル」と「署名されたレシート-micalg」パラメータの意味は次のとおりです。
1. The "signed-receipt-protocol" parameter is used to request a signed receipt from the recipient trading partner. The "signed-receipt-protocol" parameter also specifies the format in which the signed receipt SHOULD be returned to the requester.
1.「符号付き領収書プロトコル」パラメータは、受信者の貿易相手国から署名付き領収書を要求するために使用されます。 「符号付き領収書プロトコル」パラメータも署名された領収書が要求元に返されるべきフォーマットを指定します。
The "signed-receipt-micalg" parameter is a list of MIC algorithms preferred by the requester for use in signing the returned receipt. The list of MIC algorithms SHOULD be honored by the recipient from left to right.
「符号付き領収-micalg」パラメータは、返された領収書に署名する際に使用するため、要求者によって好まMICアルゴリズムのリストです。左から右へMICアルゴリズムのリストは、受信者が表彰されるべきです。
Both the "signed-receipt-protocol" and the "signed- receipt-micalg" option parameters are REQUIRED when requesting a signed receipt.
署名された領収書を要求するとき、「符号付き領収書プロトコル」および「signed-レシート-micalg」オプションパラメータの両方が必要です。
The lack of the presence of the "Receipt-Delivery-Option" indicates that a receipt is synchronous in nature. The presence of the "Receipt-Delivery-Option: return-url" indicates that an asynchronous receipt is requested and SHOULD be sent to the "return-url".
「領収書配信・オプション」の存在の欠如は、領収書が自然の中で同期していることを示しています。 「領収書配信 - オプション：リターンURL」の存在は、非同期の領収書が要求され、「リターンURL」に送信する必要があることを示します。
2. The "importance" attribute of "Optional" is defined in RFC 3798, Section 2.2, and has the following meaning:
2.「オプション」の「重要度」属性は、RFC 3798、セクション2.2で定義され、以下の意味がありますされています。
Parameters with an importance of "Optional" permit a UA that does not understand the particular options parameter to still generate an MDN in response to a request for a MDN.
「オプション」の重要性を持つパラメータは、まだMDNの要求に応じて、MDNを生成するために、特定のオプションパラメータを理解していないUAを許可します。
A UA that does not understand the "signed-receipt-protocol" parameter or the "signed-receipt-micalg" will obviously not return a signed receipt.
「符号付き領収書・プロトコル」パラメータまたは「署名し、領収書-micalg」を理解していないUAは明らかに署名した領収書を返しません。
The importance of "Optional" is used for the signed receipt parameters because it is RECOMMENDED that an MDN be returned to the requesting trading partner even if the recipient could not sign it.
受信者がそれに署名できなかった場合でも、MDNが要求して、取引先に返されることが推奨されているので、「オプション」の重要性は、署名された領収書のパラメータのために使用されています。
The returned MDN will contain information on the disposition of the message and on why the MDN could not be signed. See the Disposition field in Section 7.5 for more information.
返されたMDNはメッセージの処分にし、MDNに署名できなかった理由についての情報が含まれています。詳細については、セクション7.5での処分場を参照してください。
Within an EDI trading relationship, if a signed receipt is expected and is not returned, then the validity of the transaction is up to the trading partners to resolve.
署名した領収書が予想され、返却されていない場合、EDI取引関係の中で、トランザクションの妥当性は、解決するために、取引先までです。
In general, if a signed receipt is required in the trading relationship and is not received, the transaction will likely not be considered valid.
署名した領収書が取引関係に必要とされ、受信されない場合は、一般的には、トランザクションがおそらく有効とみなされることはありません。
The method used to request a receipt or a signed receipt is defined in RFC 3798, "An Extensible Message Format for Message Disposition Notifications".
領収書または署名された領収書を要求するために使用される方法は、「メッセージ気質通知のための広げることができるメッセージフォーマット」、RFC 3798で定義されています。
The "rules" are as follows:
次のように「ルール」は、次のとおりです。
1. When a receipt is requested, explicitly specifying that the receipt be signed, then the receipt MUST be returned with a signature.
領収書が要求されると、明示的に領収書が署名されることを指定する1は、領収書は、署名で返さなければなりません。
2. When a receipt is requested, explicitly specifying that the receipt be signed, but the recipient cannot support either the requested protocol format or the requested MIC algorithms, then either a signed or unsigned receipt SHOULD be returned.
2.場合領収書を明示的に領収書が署名されることを指定して、要求されているが、受信者は、符号付きまたは符号なしの領収書が返されるべきであるのいずれかで、その後、要求されたプロトコルの形式又は要求されたMICアルゴリズムのいずれかをサポートすることができません。
3. When a signature is not explicitly requested, or if the signed receipt request parameter is not recognized by the UA, then no receipt, an unsigned receipt, or a signed receipt MAY be returned by the recipient.
3.場合署名が明示的に要求されていない、または署名された領収書の要求パラメータがUAによって認識されない場合、何のレシート、未署名の領収書、または署名された領収書が受信者によって返さなくてもよいです。
NOTE: For Internet EDI, it is RECOMMENDED that when a signature is not explicitly requested, or if parameters are not recognized, the UA send back, at a minimum, an unsigned receipt. If, however, a signed receipt was always returned as a policy, whether requested or not, then any false unsigned receipts can be repudiated.
注：インターネットEDIのためには、署名が明示的に要求されていない場合、またはパラメータが認識されない場合、UAは、最低でも、バック未署名の領収書を送ることが推奨されます。しかし、署名領収書は常に政策として返された場合は、要求されたかどうか、そして虚偽の符号なしの領収書を否認することができます。
When a request for a signed receipt is made, but there is an error in processing the contents of the message, a signed receipt MUST still be returned. The request for a signed receipt SHALL still be honored, though the transaction itself may not be valid. The reason why the contents could not be processed MUST be set in the "disposition-field".
署名された領収書の要求がなされたが、メッセージの内容を処理する際にエラーが発生したされたときに、署名された領収書はまだ返されなければなりません。取引自体は有効ではないかもしれないが署名した領収書の要求はまだ、表彰されるものとします。内容が処理できなかった理由は、「処分場」に設定しなければなりません。
When a signed receipt request is made, the "Received-content-MIC" MUST always be returned to the requester (except when corruption prevents computation of the digest in accordance with the following specification). The "Received-content-MIC" MUST be calculated as follows:
署名された領収書の要求がなされると、「受信コンテンツMIC」は常に（破損は、以下の仕様に応じてダイジェストの計算を妨げる場合を除いて）要求元に返さなければなりません。以下のように「受信内容-MICは、」計算しなければなりません。
o For any signed messages, the MIC to be returned is calculated on the RFC1767/RFC3023 MIME header and content. Canonicalization on the MIME headers MUST be performed before the MIC is calculated, since the sender requesting the signed receipt was also REQUIRED to canonicalize.
O任意の署名されたメッセージについては、MICはRFC1767 / RFC3023のMIMEヘッダおよびコンテンツに基づいて計算されて返されます。 MICが計算される前に署名された領収書を要求し、送信者はまた、正規化する必要があったので、MIMEヘッダに正規化が行われなければなりません。
o For encrypted, unsigned messages, the MIC to be returned is calculated on the decrypted RFC 1767/RFC3023 MIME header and content. The content after decryption MUST be canonicalized before the MIC is calculated.
O暗号化された、符号なしのメッセージの場合、MICは、復号化されたRFC 1767 / RFC3023のMIMEヘッダおよびコンテンツに基づいて計算されて返されます。 MICが計算される前に復号後のコンテンツは、正規化されなければなりません。
o For unsigned, unencrypted messages, the MIC MUST be calculated over the message contents without the MIME or any other RFC 2822 headers, since these are sometimes altered or reordered by Mail Transport Agents (MTAs).
これらは時々メール転送エージェント（MTA）によって変更または並べ替えられているため、O符号なし、暗号化されていないメッセージの場合、MICは、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]に従います。論理「OR」建設を示すために、|「」この文書の修正ABNF定義は、垂直バーの文字を使用します。この用法は、RFC 2616以下の[3]。以下に参照HTTPエンティティは、さらに、この文書で定義されていません。 HTTPエンティティの完全な定義については、[3] RFC 2616を参照してください。 AS2-MDNの形式は次のとおりです。
AS2-MDN = AS2-sync-MDN | AS2-async-http-MDN | AS2-async-smtp-MDN
AS2-MDN = AS2-同期MDN | AS2-非同期HTTP-MDN | AS2-非同期SMTP-MDN
AS2-sync-MDN = Status-Line *(( general-header | response-header | entity-header ) CRLF ) CRLF AS2-MDN-body
AS2-同期MDN =ステータスラインの*（（一般ヘッダ|レスポンスヘッダ|エンティティヘッダ）CRLF）CRLFのAS2-MDN-体
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
ステータスライン= HTTP-バージョンSPステータスコードSP理由-フレーズCRLF
AS2-async-http-MDN = Request-Line *(( general-header | request-header | entity-header ) CRLF ) CRLF AS2-MDN-body
AS2-非同期HTTP-MDN =リクエストライン*（（一般ヘッダ|リクエストヘッダ|エンティティヘッダ）CRLF）CRLFのAS2-MDN-体
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
リクエストライン=メソッドのSPのRequest-URI SP HTTP-バージョンCRLF
AS2-async-smtp-MDN = *(( general-header | request-header | entity-header ) CRLF ) CRLF AS2-MDN-body
AS2-非同期SMTP-MDN = *（（一般ヘッダー|要求ヘッダー|エンティティヘッダ）CRLF）CRLFのAS2-MDNボディ
AS2-MDN-body = AS2-signed-MDN-body | AS2-unsigned-MDN-body
AS2-MDN-体= AS2署名-MDN-ボディ| AS2-符号なし - MDN-体
The AS2-MDN-body is formatted as a MIME multipart/report with a report-type of "disposition-notification". When the message is unsigned, the transfer-layer ("outermost") entity-headers of the AS2-MDN contain the content-type header that specifies a content-type of "multipart/report" and parameters indicating the report-type, and the value of the outermost multipart boundary.
AS2-MDN-体は「処分通知」のレポートタイプとMIMEマルチパート/レポートとしてフォーマットされます。メッセージが符号なしの場合、AS2-MDNの転写層（「最外」）エンティティヘッダは、「マルチパート/レポート」のコンテンツ・タイプおよびレポート・タイプを示すパラメータを指定するContent-Typeヘッダを含む、及び最も外側のマルチパート境界の値。
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の転写層（「最外」）エンティティヘッダはに使用されるアルゴリズムを示す「マルチパート/署名された」とパラメータのコンテンツタイプを指定するContent-Typeヘッダを含みますメッセージダイジェスト、署名フォーマットプロトコル（例えば、PKCS7署名）、および最外マルチパート境界の値を計算します。 MIMEマルチパート/署名されたメッセージの最初の部分は、「配置通知」タイプの埋め込みMIMEマルチパート/レポートです。マルチパート/署名されたメッセージの第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マルチパート/レポートの最初の部分は、メッセージの配置の一般的な説明を含む「人間可読」部分です。 MIMEマルチパート/レポートの第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 ]
AS2-配置通知内容= [報告-UA-フィールドCRLF] [MDNゲートウェイフィールドCRLF]最終受信者フィールドCRLF [元のメッセージ-IDフィールドCRLF] AS2-配置フィールドCRLF×（failure-フィールドCRLF）*（エラーフィールドCRLF）*（警告フィールドCRLF）*（拡張フィールドCRLF）AS2-受信コンテンツMICフィールド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処分場は、AS2-配置フィールドで置き換えられていることを除いて、[5] RFC 3798のセクション7に設けられた配置通知コンテンツルールと同一でありますそして、AS2-受信コンテンツ-MICフィールドが追加されていること。 RFC 3798処分場及びAS2-配置フィールドの違いを以下に説明します。このドキュメントとRFC 3798との間に差異がある場合は、それらのエンティティ名は事前保留「AS2-」によって変更されました。 RFC 3798と異ならないエンティティは、必ずしもさらに、この文書で定義されていません。元の文法のために、「文法を収集」、RFC 3798、セクション7を参照してください。
AS2-disposition-field = "Disposition" ":" disposition-mode ";" AS2-disposition-type [ '/' AS2-disposition-modifier ]
AS2-配置フィールド= "処分" "：" レイアウトモード ";" AS2標準の規定[「/ AS2-処分-修飾子]
disposition-mode = action-mode "/" sending-mode
気質モード=アクションモード「/」送信モード
action-mode = "manual-action" | "automatic-action"
アクション・モード=「マニュアルアクション」| 「自動アクション」
sending-mode = "MDN-sent-manually" | "MDN-sent-automatically"
送信モード= "MDN-送ら-手動" | "MDN-送られ、自動的に"
AS2-disposition-type = "processed" | "failed"
AS2-処分型= "処理" | 「失敗しました」
AS2-disposition-modifier = ( "error" | "warning" ) | AS2-disposition-modifier-extension
AS2-処分-修飾子=（ "エラー" | "警告"）| AS2-処分 - 修飾子、拡張
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-処分-修飾-拡張子= "エラー：認証に失敗しました" | 「エラー：解凍に失敗しました」| 「エラー：復号化に失敗しました」| 「エラー：不十分なメッセージセキュリティ」| |：「エラー整合性チェックは、失敗しました」 「エラー：予期しない処理エラー」| "警告：" AS2-MDN-警告説明| "失敗：" AS2-MDN失敗記述
AS2-MDN-warning-description = *( TEXT )
AS2-MDN-警告説明= *（TEXT）
AS2-MDN-failure-description = *( TEXT )
AS2-MDN障害記述= *（TEXT）
AS2-received-content-MIC-field = "Received-content-MIC" ":" encoded-message-digest "," digest-alg-id CRLF
AS2-受信コンテンツMICフィールドは= "受信コンテンツMIC" "：" 符号化メッセージ・ダイジェスト "" ダイジェスト-ALG-ID CRLF
encoded-message-digest = 1*( 'A'-Z' | 'a'-'z' | '0'-'9' | '/' | '+' | '=' ) ( i.e. base64( message-digest ) )
エンコードされたメッセージダイジェスト= 1 *（ 'A'-Z' | 'A' - 'Z' | '0' - '9' | '/' | '+' | '='）（すなわち、BASE64（message-ダイジェスト））
digest-alg-id = "sha1" | "md5"
ダイジェスト-AL-ID = "ショー1" | 「5」
"Insufficient-message-security" and "decompression-failed" are new error codes that are not mentioned in the AS1 RFC 3335, and may not be compatible with earlier implementations of AS2.
「不十分なメッセージセキュリティ」および「伸長に失敗した」AS1のRFC 3335に記載されていない新しいエラーコードであり、AS2の以前の実装と互換性がないかもしれません。
The "Received-content-MIC" extension field is set when the integrity of the received message is verified. The MIC is the base64-encoded message-digest computed over the received message with a hash function. This field is required for signed receipts but optional for unsigned receipts. For details defining the specific content over which the message digest is to be computed, see Section 7.3.1 of this document.
受信したメッセージの整合性が検証されたときに、「受信内容-MIC」拡張フィールドが設定されています。 MICは、base64エンコードされたメッセージダイジェストのハッシュ関数を用いて受信メッセージにわたって計算されます。このフィールドは、符号なしの領収書のための署名領収書が、オプションのために必要とされます。メッセージダイジェストが計算されるべき上の特定のコンテンツを定義する詳細については、本文書のセクション7.3.1を参照。
For signed messages, the algorithm used to calculate the MIC MUST be the same as that used on the message that was signed. If the message is not signed, then the SHA-1 algorithm SHOULD be used. This field is set only when the contents of the message are processed successfully. This field is used in conjunction with the recipient's signature on the MDN so that the sender can verify non-repudiation of receipt.
署名されたメッセージについては、MICを計算するために使用されるアルゴリズムは、署名されたメッセージに使用されているものと同じでなければなりません。メッセージが署名されていない場合には、SHA-1アルゴリズムを使用すべきです。このフィールドは、メッセージの内容が正常に処理されている場合にのみ設定されています。送信者が受信の否認防止を確認できるように、このフィールドは、MDNの受取人の署名と一緒に使用されます。
AS2-MDN field names (e.g., "Disposition:", "Final-Recipient:") are case insensitive (cf. RFC 3798, Section 3.1.1). AS2-MDN action-modes, sending-modes, AS2-disposition-types, and AS2-disposition-modifier values, which are defined above, and user-supplied *( TEXT ) values are also case insensitive. AS2 implementations MUST NOT make assumptions regarding the values supplied for AS2-MDN-warning-description or AS2-MDN-failure-description, or for the values of any (optional) error, warning, or failure fields.
AS2-MDNフィールド名（例えば、 "処分："、 "最終受信者："）大文字小文字を区別しない（参照、RFC 3798、セクション3.1.1）です。 AS2-MDNのアクションモード、送信モード-、AS2-配置・タイプ、および上記で定義されているAS2-配置-修飾値、およびユーザ提供*（TEXT）値も大文字と小文字を区別しています。 AS2の実装は、AS2-MDN警告記述またはAS2-MDN-障害説明のため、または任意（オプション）エラー、警告、またはエラーフィールドの値のために供給された値に関する仮定してはなりません。
o Unlike SMTP, for HTTP transactions, Original-Recipient and Final-Recipient SHOULD not be different. The value in Original-Message-ID SHOULD match the original Message-ID header value.
O SMTPとは異なり、HTTPトランザクションのために、オリジナル・受信者と最終受信者は異なるべきではありません。オリジナル・メッセージIDの値は、元のメッセージ-IDヘッダの値と一致する必要があります。
o Refer to RFC 3798 for the formatting of the MDN, except for the specific deviations mentioned above.
O前述の特定の偏差を除いて、MDNのフォーマットは、RFC 3798を参照してください。
o Refer to RFC 3462 and RFC 3798 for the formatting of the content-type entity-headers for the MDN.
O MDNのためのコンテンツタイプエンティティヘッダのフォーマットは、RFC 3462及びRFC 3798を参照のこと。
o Use an action-mode of "automatic-action" when the disposition described by the disposition type was a result of an automatic action rather than that of an explicit instruction by the user for this message.
配置の種類によって記述配置ではなく、このメッセージのためのユーザによる明示的な指示に比べて自動アクションの結果であった場合、O「自動アクション」の動作モードを使用します。
o Use an action-mode of "manual-action" when the disposition described by the disposition type was a result of an explicit instruction by the user rather than some sort of automatically performed action.
配置の種類によって記述配置は、ユーザではなく、自動的に実行されたアクションのいくつかの並べ替えによる明示的な指示の結果であった場合○「マニュアルアクション」の動作モードを使用します。
o Use a sending-mode of "MDN-sent-automatically" when the MDN is sent because the UA had previously been configured to do so.
UAが以前にそうするように構成されていたので、MDNが送信されたときにO「MDN-送ら-自動的に」の送信モードを使用してください。
o Use a sending-mode of "MDN-sent-manually" when the user explicitly gave permission for this particular MDN to be sent.
ユーザーが明示的に送信されるこの特定のMDNのための許可を与えたときO「MDN-送ら-手動」の送信モードを使用してください。
o The sending-mode "MDN-sent-manually" is meaningful ONLY with "manual-action", not with "automatic-action".
送信モードO「MDNは-手動で送信されない」「自動アクション」と、ONLY「マニュアルアクション」と意味があります。
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は、ユーザ設定制御下で送信されている場合は、「配置モード」の最初の部分は、「マニュアルアクション」に設定されるべきです。署名した領収書の要求は常に尊重されなければならないので、利用者は、送信者が1つを要求したときに署名した領収書を送信しないUAを構成するために許可されてはいけません。
The second part of the disposition-mode is set to "MDN-sent-manually" if the user gave explicit permission for the MDN to be sent. Again, the user MUST not be allowed to explicitly refuse to send a signed receipt when the sender requests one. The second part of the "disposition-mode" is set to "MDN-sent-automatically" whenever the EDI UA sends the MDN automatically, regardless of whether the sending was under the control of a user, administrator, or software.
ユーザーは、MDNを送信するための明示的な許可を与えた場合の処分モードの第2の部分は、「MDN-送ら-手動」に設定されています。ここでも、ユーザーが明示的に送信者が1を要求したときに署名した領収書を送信することを拒否することが許されてはなりません。 「配置モード」の第2の部分は、EDI UAに関係なく送信は、ユーザ、管理者、またはソフトウェアの制御下にあったかどうか、自動的にMDNを送るたびに「MDN-自動的に送信」に設定されています。
Because EDI content is generally handled automatically by the EDI UA, a request for a receipt or signed receipt will generally return the following in the "disposition-field":
EDIコンテンツは、一般的にEDI UAによって自動的に処理されるため、レシートまたは署名された領収書の要求は、一般に「処分場」に次のように返されます。
Disposition: automatic-action/MDN-sent-automatically; processed
処分：自動アクション/-送られ、自動的にMDN;処理されました
Note that this specification does not restrict the use of the "disposition-mode" just to automatic actions. Manual actions are valid as long as it is kept in mind that a request for a signed receipt MUST be honored.
この仕様は、単に自動アクションに「処分モード」の使用を制限しないことに注意してください。それが署名した領収書の要求が受け入れられなければなら念頭に置かれているよう手動アクションは限り有効です。
The request for a signed receipt requires the use of two "disposition-notification-options", which specify the protocol format of the returned signed receipt, and the MIC algorithm used to calculate the MIC over the message contents. The "disposition-field" values that should be used if the message content is being rejected or ignored (for instance, if the EDI UA determines that a signed receipt cannot be returned because it does not support the requested protocol format, the EDI UA chooses not to process the message contents itself) MUST be specified in the MDN "disposition-field" as follows:
署名された領収書の要求が返される署名された領収書のプロトコル形式、およびメッセージ内容を超えるMICを計算するために使用されるMICアルゴリズムを指定する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-配置型を使用しなければなりません。メッセージの送信者がサポートされていないメッセージの整合性チェック（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-配置-修飾子拡張障害の実装定義の説明に使用されるべきです。失敗に関するさらなる情報は、故障フィールドに含まれていてもよいです。
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"
「失敗：サポートされていないMIC-アルゴリズム」
When errors occur in processing the received message (other than content), the "disposition-field" MUST be set to the "processed" value for disposition-type and the "error" value for disposition-modifier.
誤差は（コンテンツ以外）受信したメッセージを処理する際に発生した場合、「配置フィールドは、」配置型及び配置、改質のための「誤差」値の「処理」の値に設定しなければなりません。
The "error" AS2-disposition-modifier with the "processed" disposition-type MUST be used to indicate that an error of some sort occurred that prevented successful processing of the message. Further information may be contained in an error-field.
「処理」気質タイプと「エラー」AS2-配置改質剤は、ある種のエラーメッセージの成功した処理を妨げ、その発生したことを示すために使用されなければなりません。さらなる情報は、エラー・フィールドに含まれてもよいです。
An "error:" AS2-disposition-modifier-extension SHOULD be used to combine the indication of an error with a predefined description of a specific, well-known error. Further information about the error may be contained in an error field.
「エラー：」AS2-配置-修飾子拡張は、特定のよく知られたエラーのあらかじめ定義された説明とエラーの表示を組み合わせるために使用されるべきです。エラーの詳細については、エラー・フィールドに含まれていてもよいです。
For internet EDI use, the following "error" AS2-disposition-modifier values are defined:
インターネットEDIの使用については、以下の「エラー」AS2-処分 - 修飾子の値が定義されています。
o "Error: decryption-failed" - the receiver could not decrypt the message contents.
O「エラー：復号化に失敗した」 - 受信者がメッセージの内容を解読することができませんでした。
o "Error: authentication-failed" - the receiver could not authenticate the sender.
O「エラー：認証に失敗した」 - 受信機は送信者を認証できませんでした。
o "Error: integrity-check-failed" - the receiver could not verify content integrity.
O「エラー：整合性チェック失敗しました」 - 受信機は、コンテンツの完全性を確認できませんでした。
o "Error: unexpected-processing-error" - a catch-all for any additional processing errors.
O「エラー：予期しない処理エラー」 - キャッチオール任意の追加の処理エラーのために。
An example of how the "disposition-field" would look when errors other than those in content processing are detected is as follows:
以下のように「処分・フィールド」は、コンテンツ処理中以外のエラーが検出されたときにどのように見えるかの例は次のとおりです。
Disposition: "disposition-mode"; processed/Error:
decryption-failed
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-配置-改質拡張は、警告の実装定義の記述に警告の表示を組み合わせるために使用されるべきです。警告の詳細については、警告・フィールドに含まれていてもよいです。
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
7.5.6. Backward Compatibility with Disposition Type, Modifier, and Extension
7.5.6. 処分タイプ、修飾子、および拡張との下位互換性
The following set of examples represents typical constructions of the Disposition field that have been in use by AS2 implementations. This is NOT an exhaustive list of possible constructions. However, AS2 implementations MUST accept constructions of this type to be backward compatible with earlier AS2 versions.
実施例の以下のセットは、AS2の実装によって使用されてきた処分場の典型的な構成を表します。これは可能な構造の完全なリストではありません。しかし、AS2の実装は、以前のAS2バージョンとの下位互換性があるように、このタイプの構成を受け入れなければなりません。
Disposition: automatic-action/MDN-sent-automatically; processed
処分：自動アクション/-送られ、自動的にMDN;処理されました
Disposition: automatic-action/MDN-sent-automatically; processed/error: authentication-failed
処分：自動アクション/-送られ、自動的にMDN;処理された/エラー：認証失敗
Disposition: automatic-action/MDN-sent-automatically; processed/warning: duplicate-document
処分：自動アクション/-送られ、自動的にMDN;処理された/警告：重複文書
Disposition: automatic-action/MDN-sent-automatically; failed/failure: sender-equals-receiver
処分：自動アクション/-送られ、自動的にMDN;失敗/失敗：送信者に等しく、受信機
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;処理されました
Disposition: automatic-action/MDN-sent-automatically; processed/error: decryption-failed Error: The signature did not decrypt into a valid PKCS#1 Type-2 block. Error: The length of the decrypted key does not equal the octet length of the modulus.
処分：自動アクション/-送られ、自動的にMDN;処理された/エラー：復号化に失敗したエラー：署名が有効なPKCS＃1タイプ2ブロックに復号化できませんでした。エラー：復号化されたキーの長さがモジュラスのオクテット長を等しくありません。
Disposition: automatic-action/MDN-sent-automatically; processed/warning: duplicate-document Warning: An identical message already exists at the destination server.
処分：自動アクション/-送られ、自動的にMDN;処理された/警告：重複文書警告：同じメッセージがすでに宛先サーバーに存在します。
Disposition: automatic-action/MDN-sent-automatically; failed/failure: sender-equals-receiver Failure: The AS2-To name is identical to the AS2-From name.
処分：自動アクション/-送られ、自動的にMDN;失敗/失敗：送信者-等しい-受信障害：AS2-に名前がAS2-から名前と同じです。
The following set of examples represents allowable constructions of the Disposition field that employ pure RFC 3798 Disposition-modifiers with optional error, warning, and failure fields. These examples are provided as informational only. These constructions are not guaranteed to be backward compatible with AS2 implementations prior to version 1.1.
実施例の以下のセットは、オプションのエラー、警告、故障フィールドを持つ純粋なRFC 3798処分 - 修飾子を使用処分場の許容構造を表します。これらの例は、情報としてのみ提供されています。これらの構造は、バージョン1.1より前AS2実装との下位互換性があることが保証されていません。
Disposition: automatic-action/MDN-sent-automatically; processed
処分：自動アクション/-送られ、自動的にMDN;処理されました
Disposition: automatic-action/MDN-sent-automatically; processed/error Error: authentication-failed Error: The signature did not decrypt into a valid PKCS#1 Type-2 block. Error: The length of the decrypted key does not equal the octet length of the modulus.
処分：自動アクション/-送られ、自動的にMDN;処理された/エラーエラー：認証失敗エラー：署名が有効なPKCS＃1タイプ2ブロックに復号化できませんでした。エラー：復号化されたキーの長さがモジュラスのオクテット長を等しくありません。
Disposition: automatic-action/MDN-sent-automatically; processed/warning Warning: duplicate-document
処分：自動アクション/-送られ、自動的にMDN;処理された/警告警告：重複し、文書
Disposition: automatic-action/MDN-sent-automatically; failed Failure: sender-equals-receiver
処分：自動アクション/-送られ、自動的にMDN;失敗した失敗：送信者イコール、受信機
The details of the response to the POST command vary depending upon whether a receipt has been requested.
POSTコマンドへの応答の詳細は領収書が要求されているかどうかによって異なります。
With no extended header requesting a receipt, and with no errors accessing the request-URI specified processing, the status line in the Response to the POST request SHOULD be in the 200 range. Status codes in the 200 range SHOULD also be used when an entity is returned (a signed receipt in a multipart/signed content type or an unsigned receipt in a multipart/report). Even when the disposition of the data was an error condition at the authentication, decryption or other higher level, the HTTP status code SHOULD indicate success at the HTTP level.
全く拡張ヘッダが受信を要求していない、とエラーなしで要求URI処理を指定したアクセスすると、POST要求に応答して、ステータスライン200の範囲にあるべきです。エンティティは（マルチパート/署名されたコンテンツ・タイプまたはマルチパート/レポートの符号なしレシートに署名された領収書）に戻されたとき200の範囲内のステータス・コードも使用されるべきです。データの配置は、認証、復号又は他のより高いレベルのエラー状態であった場合でも、HTTPステータスコードは、HTTPレベルでの成功を示すべきです。
The HTTP server-side application may respond with an unsolicited multipart/report as a message body that the HTTP client might not have solicited, but the client may discard this. Applications SHOULD avoid emitting unsolicited receipt replies because bandwidth or processing limitations might have led administrators to suspend asking for acknowledgements.
HTTPサーバ側のアプリケーションは、HTTPクライアントが要請していない可能性がありますメッセージの本文として迷惑マルチパート/レポートで応答することができるが、クライアントはこれを破棄してもよいです。帯域幅や処理の制限が確認応答を求めて一時停止する管理者を率いてきた可能性があるため、アプリケーションは迷惑領収書の返信を放出することは避けてください。
Message Disposition Notifications, when used in the HTTP reply context, will closely parallel a SMTP MDN. For example, the disposition field is a required element in the machine-readable second part of a multipart/report for a MDN. The final-recipient-field ([5], Section 3.1) value SHOULD be derived from the entity headers of the request.
メッセージ気質通知は、HTTP応答の文脈で使用される場合、密接にSMTP MDNに平行になります。例えば、配置フィールドは、MDNのためのマルチパート/レポートの機械読み取り可能な第二の部分に必要な元素です。最終受信者フィールド（[5]、セクション3.1）値要求のエンティティヘッダから誘導されるべきです。
In an MDN, the first part of the multipart/report (the human-readable part) SHOULD include items such as the subject, the date, and other information when those fields are present in entity header fields following the POST request. An application MUST report the Message-ID of the request in the second part of the multipart/report (the machine-readable part). Also, an MDN SHOULD have its own unique Message-ID HTTP header. The HTTP reply SHOULD normally omit the third optional part of the multipart/report (used to return the original message or its headers in the SMTP context).
MDNでは、マルチパート/レポートの最初の部分（人間可読部分）は、件名、日付、およびPOSTリクエスト以下これらのフィールドは、エンティティヘッダフィールド内に存在する他の情報などの項目が含まれるべきです。アプリケーションは、マルチパート/レポート（機械可読部）の第二の部分におけるリクエストのメッセージIDを報告しなければなりません。また、MDNは独自のMessage-ID HTTPヘッダーを持っているべきです。 HTTP応答は、通常、（SMTP文脈における元のメッセージまたはそのヘッダを返すために使用される）マルチパート/レポートの第三のオプションの一部を省略すべきです。
In the near term, the exchange of public keys and certification of these keys MUST be handled as part of the process of establishing a trading partnership. The UA and/or EDI application interface must maintain a database of public keys used for encryption or signatures, 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].
[12]に助言を考慮し、取引パートナーはS / MIMEを使用しているとき、彼らはまた、公開鍵証明書を交換することが推奨されます。
The message formats useful for certificate exchange are found in [7] and [13].
証明書交換のために有用なメッセージフォーマットは、に見出される[7]および[13]。
In the long term, additional standards may be developed to simplify the process of establishing a trading partnership, including the third-party authentication of trading partners, as well as the attributes of the trading relationship.
長期的には、追加的な基準は、取引先のサードパーティの認証だけでなく、取引関係の属性を含む、取引パートナーシップを確立するプロセスを簡素化するために開発されてもよいです。
This entire document is concerned with secure transport of business to business data, and it considers both data confidentiality and authentication issues.
この文書全体では、ビジネスデータへの事業の安全な輸送と懸念している、そしてそれは、データの機密性と認証の両方の問題を検討します。
Extracted from RFC 3851 [7]: 40-bit encryption is considered weak by most cryptographers. Using weak cryptography in S/MIME offers little actual security over sending plaintext. However, other features of S/MIME, such as the specification of Triple DES and the ability to announce stronger cryptographic capabilities to parties with whom you communicate, allow senders to create messages that use strong encryption. Using weak cryptography is never recommended unless the only alternative is no cryptography. When feasible, sending and receiving agents SHOULD inform senders and recipients of the relative cryptographic strength of messages.
RFC 3851から抽出された[7]：40ビットの暗号化は、ほとんどの暗号によって弱いと考えられます。 S / MIMEで弱い暗号を使用すると、プレーンテキストを送信する上で少し実際のセキュリティを提供しています。しかし、そのようなトリプルDES、あなたは誰と通信する相手に強力な暗号化機能を発表する能力の仕様として、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.
証明書の証明書失効リスト（CRL）をチェックする能力を、O。
o An invalid CRL was received.
O無効CRLを受信しました。
o The CRL being checked is expired.
OチェックされるCRLは有効期限が切れています。
o The certificate is expired.
O証明書の有効期限が切れています。
o The certificate has been revoked.
O証明書が失効しています。
There are certainly other instances where a certificate may be invalid, and it is the responsibility of the processing software to check them all thoroughly, and to decide what to do if the check fails. See RFC 3280 for additional information on certificate path validation.
そこ証明書が無効になる可能性のある他のインスタンスは確かであり、それは徹底的にそれらすべてをチェックするために、チェックが失敗した場合に何をすべきかを決定するために、処理ソフトウェアの責任です。証明書パス検証の詳細については、RFC 3280を参照してください。
The following are additional security considerations to those listed in [7] and [12].
[7]および[12]に記載されたものに追加のセキュリティ上の考慮事項は次のとおり。
This specification seeks to provide multiple mechanisms that can be combined in accordance with local policies to achieve a wide range of security needs as determined by threat and risk analyses of the business peers. It is required that all these mechanisms be implemented by AS2 software so that the software has capabilities that promote strong interoperability, no matter what policies are adopted.
この仕様は、ビジネス・ピアの脅威とリスクの分析によって決定されるようなセキュリティニーズの広い範囲を達成するために、ローカルポリシーに従って組み合わせることができ、複数のメカニズムを提供することを目的とします。ソフトウェアは関係なく採用されているどのような政策、強力な相互運用性を促進しない能力を持っているように、すべてのこれらのメカニズムはAS2ソフトウェアで実現することが必要です。
One strong cluster of mechanisms (the secure transmission loop) can provide good support for meeting the evidentiary needs of non-repudiation of receipt by the original sender and by a third party supplied with all stated evidence. However, this specification does not itself define non-repudiation of receipt nor enumerate its essential properties because NRR is a business analysis and/or legal requirement, and not relevantly defined by a technical applicability statement.
メカニズムの一つの強力なクラスタ（セキュア伝送ループ）は、元の送信者によって、すべての述べられた証拠に付属の第三者による受領の否認防止の証拠ニーズを満たすための良いサポートを提供することができます。 NRRは、ビジネス分析および/または法的要件であり、意義が技術的な適用性の文で定義されていないので、しかし、この仕様自体が領収書の否認防止を定義もその本質的な特性を列挙しません。
Some analyses observe that non-repudiation of receipt presupposes that non-repudiation of the sender of the original message is obtained, and further that non-repudiation should be implemented by means of digital signature on the original message. To satisfy strict NRR evidence, authentication and integrity MUST be provided by some mechanism, and the RECOMMENDED mechanism is digital signatures on both the original message and the receipt message.
いくつかの分析は、受領の否認防止は、元のメッセージの送信者の否認防止が得られ、さらにその否認防止は、元のメッセージのデジタル署名を用いて実施されるべきであることを前提としていることを観察します。厳密NRR証拠を満たすために、認証と完全性は、いくつかのメカニズムによって提供されなければならない、推奨メカニズムは、元のメッセージと受信メッセージの両方にデジタル署名です。
Given that this specification has selected several mechanisms that can be combined in several ways, it is important to realize that if a digital signature is omitted from the original message, in order to satisfy the preceding analysis of NRR requirements, some authentication mechanism MUST accompany the request for a signed receipt and its included Received-content-MIC value. This authentication might come from using client-side SSL, authentication via IPsec, or HTTP authentication (while using SSL). In any case, records of the message content, its security basis, and the digest value need to be retained for the NRR process.
この仕様は、いくつかの方法で組み合わせることができるいくつかのメカニズムを選択したことを考えれば、デジタル署名は、元のメッセージから省略された場合、NRR要件の前の分析を満たすために、いくつかの認証メカニズムを添付しなければならないことを理解することは重要です署名領収書及びその付属受信コンテンツ-MIC値を要求。この認証は、IPsec、またはHTTP認証（SSLを使用している）を介してクライアント側のSSL認証を使用してから来るかもしれません。いずれの場合も、メッセージの内容、そのセキュリティ基盤、およびダイジェスト値の記録は、NRRプロセスのために保持する必要があります。
Therefore, if NRR is one of the goals of the policy that is adopted, by using the mechanisms of the secure transmission loop mentioned above and by retaining appropriate records of authentication at the original message sender site, strong evidentiary requirements proposed for NRR can be fulfilled.
したがって、NRRがNRRのために提案されている強力な証拠要件を満たすことができる、上述したセキュアな送信ループのメカニズムを使用して、元のメッセージの送信者サイトでの認証の適切な記録を保持することによって、採用されているポリシーの目標の一つである場合。
Other ways of proceeding may fall short of fulfilling the most stringent sets of evidence required for NRR to obtain, but may nevertheless be part of a commercial trading agreement and, as such, are good enough for the parties involved. However, if MDNs are returned unsigned, evidentiary requirements for NRR are weak; some authentication of the identity of the receiver is needed.
手続の他の方法は、取得するためにNRRのために必要な証拠の最も厳しいセットを満たすを下回ることがあり、それにもかかわらずなど、当事者のために十分に優れている、商用取引契約の一部であるとも。開封通知が符号なし返された場合は、NRRのための証拠の要件は弱いです。受信機のアイデンティティの一部の認証が必要とされています。
The following certificate types MUST be supported for SSL server-side certificates:
次の証明書の種類は、SSLサーバー側の証明書をサポートしなければなりません：
o with URL in the Distinguished Name Common Name attribute
識別名一般名属性にURLを持つO
o without URL in the Distinguished Name Common Name attribute
識別名一般名属性にURLなしO
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は、二つの処分 - 通知 - オプションのパラメータを登録しました
Parameter-name: signed-receipt-protocol Parameter-name: signed-receipt-micalg
パラメータ名：符号付き領収書プロトコルのパラメータ名：符号付き領収書micalg
that are also used by this specification (see Section 7.3).
また、この仕様で使用されている（7.3節を参照してください）。
RFC 3335 also registered on MDN Extension field name
RFC 3335はまた、MDN拡張フィールド名に登録します
Extension field name: Received-content-MIC
拡張フィールド名：受信コンテンツ-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.
カール・ヘイグ、カレン・ローゼンフェルド、チャック・フェントン、および他の多くは、この適用性声明を改善貴重な提案を提供してきました。著者らはまた、ドラモンドグループ本社AS2の相互運用性テストに参加したベンダーに感謝したいと思います。彼らの貢献は、この文書の明瞭さの大幅な向上につながりました。
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[1]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
解放された、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート5：適合基準と例"、RFC 2049、1996年11月。
[2] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, March 1995.
[2]クロッカー、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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - 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]ハーディング、T.、ドラモンド、R.、およびC.シーズー、「インターネット上でのMIMEベースのセキュアなピア・ツー・ピアのビジネスデータ交換」、RFC 3335、2002年9月。
[5] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[5]ハンセン、T.およびG.ボードルイ、 "メッセージ気質通知"、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]ガルビン、J.、マーフィー、S.、クロッカー、S.、およびN.フリード、 "MIMEマルチパートのセキュリティ：マルチパート/署名およびマルチパート/暗号化"、RFC 1847、1995年10月に。
[7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[7] Ramsdell、B.、RFC 3851、2004年7月 "/多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様を固定します"。
[8] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[8]ヴォードルイユ、G.、RFC 3462「メールシステムの管理メッセージの報告のための複合/レポートのコンテンツタイプ」、2003年1月。
[9] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[9]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[10] Murata, M., Laurent, S. St., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[10]村田、M.、ローラン、S.セント、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[11] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[11]ブラドナーの、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.は、RFC 3850、2004年7月、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1証明書の取り扱い"。
[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]クロッカー、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]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
Appendix A: Message Examples
付録A：メッセージの例
NOTE: All examples are provided for illustration only, and are not considered part of the protocol specification. If an example conflicts with the protocol definitions specified above or in the other referenced RFCs, the example is wrong.
注：すべての例は、例示のみのために提供され、およびプロトコル仕様の一部とみなされません。例では、他の参照RFCの上または中に指定されたプロトコルの定義と矛盾する場合は、例は、間違っています。
A.1. Signed Message Requesting a Signed, Synchronous Receipt
A.1。署名、同期領収書を要求する署名付きのメッセージ
POST /receive HTTP/1.0 Host: 10.234.160.12:80 User-Agent: AS2 Company Server Date: Wed, 31 Jul 2002 13:34:50 GMT From: mrAS2@example.com AS2-Version: 1.1 AS2-From: "\" as2Name \"" AS2-To: 0123456780000 Subject: Test Case Message-Id: <200207310834482A70BF63@\"~~foo~~\"> Disposition-Notification-To: mrAS2@example.com Disposition-Notification-Options: signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional,sha1 Content-Type: multipart/signed; boundary="as2BouNdary1as2"; protocol="application/pkcs7-signature"; micalg=sha1 Content-Length: 2464
POST /受信HTTP / 1.0ホスト：10.234.160.12:80のUser-Agent：AS2会社サーバ日：水曜日、2002年7月31日13時34分50秒GMTから：mrAS2@example.com AS2-バージョン：1.1 AS2-から： " \」as2Nameの\ "" AS2-TO：0123456780000件名：テストケースのメッセージ-ID：<200207310834482A70BF63 @ "~~ FOO ~~ \" \>処分-通知-TO：mrAS2@example.com処分 - 通知 - オプション：署名-receiptプロトコル=オプション、PKCS7署名。署名されたレシート-micalg =オプション、SHA1のコンテンツタイプ：マルチパート/署名されました。境界=「as2BouNdary1as2」。プロトコル=「アプリケーション/ PKCS7署名」。 micalg = SHA1のContent-Length：2464
--as2BouNdary1as2 Content-Type: application/edi-x12 Content-Disposition: Attachment; filename=rfc1767.dat [ISA ...EDI transaction data...IEA...]
--as2BouNdary1as2のContent-Type：アプリケーション/ EDI-X12のContent-処分：添付ファイル;ファイル名= rfc1767.dat [ISA ... EDI取引データ... IEA ...]
--as2BouNdary1as2 Content-Type: application/pkcs7-signature
--as2BouNdary1as2のContent-Type：アプリケーション/ PKCS7署名
[omitted binary pkcs7 signature data] --as2BouNdary1as2--
【省略バイナリPKCS7署名データ] --as2BouNdary1as2--
A.2. MDN for Message A.1, Above
A.2。メッセージA.1、上記のためのMDN
HTTP/1.0 200 OK
AS2-From: 0123456780000
AS2-To: "\" as2Name \""
AS2-Version: 1.1
Message-ID: <709700825.1028122454671.JavaMail@ediXchange>
Content-Type: multipart/signed; micalg=sha1;
protocol="application/pkcs7-signature";
boundary="----=_Part_57_648441049.1028122454671"
Connection: Close
Content-Length: 1980
コンテンツの長さ：1980
------=_Part_57_648441049.1028122454671
& 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".)
「MIMEのためのS / MIMEメッセージ仕様、PKCSセキュリティサービス」を参照し、プロトコル=「アプリケーション/ PKCS7署名」で署名されたマルチパート/準備する方法の詳細について2）。
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.
マルチパート/レポートのテキスト第1本体部が配置ヘッダーによって報告されたエラー条件のより詳細な説明を含めるために使用することができることに留意されたいです。マルチパート/レポートの最初の本体部分は、このような方法で使用されたとき、人はより良い詳細に問題を診断することができます。
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]、元の又はマルチパートの第3の本体部における元のメッセージの一部を返す/レポートが必要とされません。これはオプションの身体の部分です。しかし、この身体の部分が省略されるか空白のままにすることが推奨されます。
A.3. Signed, Encrypted Message Requesting a Signed, Asynchronous Receipt
A.3。署名、非同期の領収書を要求する署名、暗号化されたメッセージ
Message-ID: <#as2_company#01#a4260as2_companyout#> Date: Thu, 19 Dec 2002 15:04:18 GMT From: me@example.com Subject: Async MDN request Mime-Version: 1.0 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: binary Content-Disposition: attachment; filename=smime.p7m Recipient-Address: 10.240.1.2// Disposition-Notification-To: http://10.240.1.2:8201/exchange/as2_company Disposition-Notification-Options: signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional,sha1 Receipt-Delivery-Option: http://10.240.1.2:8201/exchange/as2_company AS2-From: as2_company AS2-To: "AS2 Test" AS2-Version: 1.1 Host: 10.240.1.2:8101 Connection: close Content-Length: 3428
メッセージID：<＃as2_company＃01＃a4260as2_companyout＃>日付：木、2002年12月19日午後三時04分18秒GMTから：me@example.com件名：非同期MDN要求のMime-バージョン：1.0のContent-Type：アプリケーション/ PKCS7 -mime; SMIME型=エンベロープデータ。名前= smime.p7mというコンテンツ転送エンコード：バイナリコンテンツディスポジション：添付ファイル;ファイル名= smime.p7mという受取人住所：10.240.1.2//処分-通知-TO：http://10.240.1.2:8201/exchange/as2_company処分-NOTIFICATION-オプション：符号付き領収書プロトコル=オプション、PKCS7署名;符号付き領収-micalg =オプション、SHA1領収書配信 - オプション：http://10.240.1.2:8201/exchange/as2_company AS2-から：as2_company AS2-へ： "AS2テスト" AS2-バージョン：1.1ホスト：10.240。 1.2：8101接続：閉じるのContent-Length：3428
[omitted binary encrypted data]
[バイナリ暗号化データを省略]
A.4. Asynchronous MDN for Message A.3, Above
A.4。メッセージA.3、上記のための非同期MDN
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> <MDN要求非同期>件名とGMTが受信された午前15時04分18秒2002年12月（木）、19日に受信者<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
報告-UA：AS2の@テスト：8101オリジナル・受信者：RFC822; 「AS2のテスト」最終受信者：RFC822; "AS2試験" オリジナル・メッセージID：<＃as2_company＃01＃a4260as2_companyout＃>処分：自動アクション/ MDN-送信-自動的。処理された受信 - コンテンツ-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=
BhbWjEfbyXoTAS / H0zpnEqLqbaBh29y2v82b8bdeGw8pipBQWmf53hIcqHGM 4ZBF3CHw5Wrf1JIE + 8TwOzdbal30zeChw88WfRfD7c / j1fIA8sxsujvf2d9j UxCUga8BVdVB9kH0Geexytyt0KvWQXfaEEcgZGUAAAAAAAA =
------=_Part_337_6452266.1040310218750-
Authors' Addresses
著者のアドレス
Dale Moberg Cyclone Commerce 8388 E. Hartford Drive, Suite 100 Scottsdale, AZ 85255 USA
デールMobergサイクロンコマース8388 E.ハートフォードドライブ、スイート100スコッツデール、AZ 85255 USA
EMail: dmoberg@cyclonecommerce.com
メールアドレス：dmoberg@cyclonecommerce.com
Rik Drummond Drummond Group Inc. 4700 Bryant Irvin Court, Suite 303 Fort Worth, TX 76107 USA
RIKドラモンドドラモンドグループ・インク4700ブライアントアービン裁判所、スイート303フォートワース、TX 76107 USA
EMail: rvd2@drummondgroup.com
メールアドレス：rvd2@drummondgroup.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。