[要約] RFC 4823は、インターネット上での安全なピアツーピアビジネスデータのやり取りのためのFTPトランスポートに関する規格です。このRFCの目的は、セキュリティを確保しながらビジネスデータの交換を効率的に行うためのガイドラインを提供することです。
Network Working Group T. Harding
Request for Comments: 4823 R. Scott
Category: Informational Axway
April 2007
FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet
安全なピアツーピアのビジネスデータのためのFTPトランスポートインターネットを介して交換
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message.
この適用性ステートメント（AS）は、XML、バイナリ、電子データインターチェンジ（EDI-ANSI X12またはUN/EDIFACT）のファイル転送プロトコル（FTP）を使用して構造化されたビジネスデータを安全に交換する方法を説明しています。標準のMIMEコンテンツタイプを使用してMIMEパッケージを実現できるビジネスデータインターチェンジ。認証とデータの機密性は、暗号化メッセージの構文（S/MIME）セキュリティボディパーツを使用して取得されます。認証された謝辞は、元のメッセージへのマルチパート/署名された返信を採用しています。
Table of Contents
目次
1. Introduction ....................................................4
2. Overview ........................................................4
2.1. Overall Operations .........................................4
2.2. Purpose of a Security Guideline for MIME EDI ...............5
2.3. Definitions ................................................5
2.3.1. Terms ...............................................5
2.3.2. The Secure Transmission Loop ........................6
2.3.3. Definition of Receipts ..............................7
2.4. Operational Assumptions and Options ........................8
2.4.1. EDI/EC Process Assumptions ..........................8
2.4.2. Process Options .....................................8
2.4.2.1. Security Options ...........................8
2.4.2.2. Compression Options .......................10
3. Referenced RFCs and Their Contribution .........................10
3.1. RFC 959: File Transfer Protocol [3] .......................10
3.2. RFC 2228: FTP Security Extensions [4] .....................10
3.3. RFC 1847: MIME Security Multiparts [7] ....................10
3.4. RFC 3462: Multipart/Report [12] ...........................11
3.5. RFC 1767: EDI Content [2] .................................11
3.6. RFCs 2045, 2046, and 2049: MIME [1] .......................11
3.7. RFC 3798: Message Disposition Notification [6] ............11
3.8. RFC 3852: CMS [9] and RFC 3851: S/MIME Version 3.1
Message Specification [10] ................................11
3.9. RFC 3850: S/MIME Version 3.1 Certificate Handling [11] ....11
3.10. RFC 3274: Compressed Data Content Type for
Cryptographic Message Syntax (CMS) [17] ..................11
3.11. RFC 3023: XML Media Types [16] ...........................12
4. Structure of an AS3 Message ....................................12
4.1. Introduction ..............................................12
4.2. Structure of an Internet EDI MIME Message .................12
5. AS3-Specific Headers ...........................................13
5.1. AS3-From and AS3-To Headers ...............................13
5.2. AS3-Version Header ........................................14
6. FTP Considerations .............................................15
6.1. FTP Security Requirements .................................15
6.2. Large File Transfers ......................................15
6.3. MIME Considerations for FTP ...............................15
6.3.1. Required/Optional Headers ..........................15
6.3.2. Content-Transfer-Encoding ..........................16
6.3.3. Epilogue Must Be Empty .............................16
6.3.4. Message-Id and Original-Message-Id .................16
7. Structure and Processing of an MDN Message .....................17
7.1. Introduction ..............................................17
7.2. Message Disposition Notifications (MDN) ...................19
7.3. Requesting a Signed Receipt ...............................19
7.3.1. Signed Receipt Considerations ......................22
7.4. MDN Format and Value ......................................23
7.4.1. AS3-MDN General Formats ............................23
7.4.2. AS3-MDN Construction ...............................24
7.4.3. AS3-MDN Fields .....................................25
7.4.4. Additional AS3-MDN Programming Notes ...............26
7.5. Disposition Mode, Type, and Modifier ......................29
7.5.1. Disposition Mode Overview ..........................29
7.5.2. Successful Processing Status Indication ............29
7.5.3. Unsuccessful Processed Content .....................29
7.5.4. Unsuccessful Non-Content Processing ................30
7.5.5. Processing Warnings ................................31
8. Public Key Certificate Handling ................................32
9. Security Considerations ........................................33
10. References ....................................................34
10.1. Normative References .....................................34
10.2. Informative References ...................................36
Appendix A. Message Examples ......................................37
A.1. Signed Message Requesting a Signed Receipt ................37
A.2. MDN for Message A.1 Above .................................37
Previous work on Internet EDI focused on specifying MIME content types for EDI data [2] and extending this work to support secure EC/EDI transport over SMTP [5]. This document expands on RFC 1767 to specify a comprehensive set of data security features, specifically, data privacy, data integrity, authenticity, non-repudiation of origin, and non-repudiation of receipt over FTP. This document also recognizes contemporary RFCs and is attempting to "re-invent" as little as possible. While this document focuses on EDI data, any other data type describable in a MIME format is also supported.
インターネットEDIに関する以前の研究は、EDIデータのMIMEコンテンツタイプを指定し[2]、SMTPよりも安全なEC/EDI輸送をサポートするためにこの作業を拡張することに焦点を当てていました[5]。このドキュメントは、RFC 1767で拡張され、データセキュリティ機能の包括的なセット、具体的にはデータプライバシー、データの整合性、信頼性、原産地の非繰り返し、FTPを介した領収書の非繰り返しを指定します。このドキュメントはまた、現代のRFCを認識しており、可能な限り「再発明」しようとしています。このドキュメントはEDIデータに焦点を当てていますが、MIME形式で説明可能な他のデータ型もサポートされています。
Internet MIME-based EDI can be accomplished by using and complying with the following documents:
インターネットMIMEベースのEDIは、次のドキュメントを使用および遵守することで実現できます。
- RFC 959: File Transfer Protocol - RFC 2228: FTP Security Extensions - RFC 1767: EDI Content Type - RFC 3023: XML Media Types - RFC 1847: Security Multiparts for MIME - RFC 3462: Multipart/Report - RFCs 2045 to 2049: MIME - RFC 3798: Message Disposition Notification - RFCs 3850, 3851, and 3852: S/MIME v3.1 Specifications - RFC 3274: Compressed Data Content for Cryptographic Message Syntax - RFC 4217: Securing FTP with TLS - "Compressed Data for EDIINT" by T. Harding
- RFC 959：ファイル転送プロトコル-RFC2228：FTPセキュリティ拡張機能-RFC 1767：EDIコンテンツタイプ-RFC 3023：XMLメディアタイプ-RFC 1847：MIMEのセキュリティマルチパート-RFC3462：マルチパート/レポート-RFCS 2045から2049：RFC 3798：メッセージ気質通知-RFCS 3850、3851、および3852：S/MIME V3.1仕様 - RFC 3274：RFC 3274：暗号化メッセージの構文の圧縮データコンテンツ-RFC 4217の圧縮データコンテンツ-RFC 4217：TLSでFTPを保護する - 」。ハーディング
Our intent here is to define clearly and precisely how these are used together, and what is required by user agents to be compliant with this document.
ここでの私たちの意図は、これらがどのように使用されるか、そしてユーザーエージェントがこのドキュメントに準拠するために必要なものを明確かつ正確に定義することです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [19].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [19]に記載されているように解釈される。
An FTP upload operation is used to send appropriately packaged EDI, XML, or other business data. The receiving application will poll the FTP server for inbound messages, unpackage and handle the message data, and generate a reply for the originator that contains a message disposition acknowledgement within a multipart/report that is signed or unsigned. This request/reply transactional interchange provides secure, reliable, and authenticated transport for EDI or other business data using FTP. The security protocols and structures used also support auditable records of these transmissions.
FTPアップロード操作は、適切にパッケージ化されたEDI、XML、またはその他のビジネスデータを送信するために使用されます。受信アプリケーションは、インバウンドメッセージのFTPサーバーを投票し、メッセージデータを解き放ち、処理し、署名または署名されているマルチパート/レポート内にメッセージ処分確認を含むオリジネーターの返信を生成します。このリクエスト/返信トランザクションインターチェンジは、FTPを使用して、EDIまたはその他のビジネスデータの安全で信頼性の高い認証された輸送を提供します。使用されるセキュリティプロトコルと構造は、これらの送信の監査可能な記録もサポートしています。
The purpose of these specifications is to ensure interoperability between B2B Electronic Commerce user agents, invoking some or all of the commonly expected security features. This document is also NOT limited to strict EDI use, but applies to any electronic commerce application where business data needs to be exchanged over the Internet in a secure manner.
これらの仕様の目的は、B2B Electronic Commerceユーザーエージェント間の相互運用性を確保し、一般的に期待されるセキュリティ機能の一部またはすべてを呼び出すことです。このドキュメントは、厳密なEDI使用に限定されませんが、ビジネスデータを安全な方法でインターネットで交換する必要がある電子商取引アプリケーションに適用されます。
AS3 Applicability Statement 3. This is the third applicability statement produced by the IETF EDIINT working group.
AS3アプリケーションステートメント3.これは、IETF EDIINTワーキンググループが作成した3番目のアプリケーションステートメントです。
EDI Electronic Data Interchange
EDI電子データインターチェンジ
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.
受信者から送信者に送信される機能的なメッセージを受領して、EDI/ECインターチェンジの受領を確認します。
Signed Receipt A receipt containing a digital signature.
署名された領収書デジタル署名を含む領収書。
Message Disposition The Internet messaging format used to convey a Notification (MDN) receipt. This term is used interchangeably with receipt. An MDN is a receipt.
メッセージ処分通知（MDN）領収書を伝えるために使用されるインターネットメッセージング形式。この用語は、領収書と同じ意味で使用されます。MDNは領収書です。
Non-repudiation of NRR is a "legal event" that occurs when the receipt (NRR) original sender of an EDI/EC interchange has verified the signed receipt coming back from the receiver. NRR IS NOT a functional or a technical message.
NRRの非繰り返しは、EDI/ECインターチェンジの領収書（NRR）の元の送信者がレシーバーから戻ってくる署名領収書を確認したときに発生する「法的イベント」です。NRRは機能的なメッセージでも技術的なメッセージでもありません。
S/MIME A format and protocol for adding Cryptographic signature and/or encryption services to Internet MIME messages.
S/MIMEインターネットMIMEメッセージに暗号化署名および/または暗号化サービスを追加するための形式とプロトコル。
NOTE: While the S/MIME specification describes more than one format for a signed message, all signed messages or receipts used with AS3 MUST utilize the multipart/signed format.
注：S/MIME仕様は、署名されたメッセージの複数の形式を説明していますが、AS3で使用されるすべての署名済みメッセージまたは領収書は、MultiPart/署名された形式を使用する必要があります。
SHA-1 A secure, one-way hash algorithm used in conjunction with digital signature. SHA-1 is the recommend algorithm for AS3.
SHA-1デジタル署名と組み合わせて使用される安全な一元配置ハッシュアルゴリズム。SHA-1は、AS3の推奨アルゴリズムです。
MD5 A secure, one-way hash algorithm used in conjunction with digital signature. This algorithm is acceptable but not recommended due to its short key length and known weaknesses.
MD5デジタル署名と組み合わせて使用される安全な一元配置ハッシュアルゴリズム。このアルゴリズムは受け入れられますが、キーの長さが短く既知の弱点のために推奨されません。
MIC The message integrity check (MIC) is a representation of the message digest, which results from the application of the selected hash algorithm to the content to be signed. Of particular interest is the digital signature, which includes an encrypted copy of the digest. Additionally, an MDN containing a Received-content-MIC header will also contain (as that header's value) a base-64-encoded representation of the digest.
MICメッセージIntegrity Check（MIC）は、メッセージダイジェストの表現であり、選択したハッシュアルゴリズムを署名するコンテンツに適用します。特に興味深いのは、Digestの暗号化されたコピーを含むデジタル署名です。さらに、受信コンテンツMICヘッダーを含むMDNには、（そのヘッダーの値として）ダイジェストのベース64エンコード表現も含まれます。
User Agent (UA) The application that handles and processes the AS3 request.
ユーザーエージェント（UA）AS3要求を処理および処理するアプリケーション。
STL Secure Transmission Loop, described in the next section.
次のセクションで説明するSTLセキュアトランスミッションループ。
This document's focus is on the formats and protocols for exchanging EDI/EC content to which security services have been applied using the File Transmission Protocol (FTP) as the transport.
このドキュメントの焦点は、ファイル送信プロトコル（FTP）を輸送として使用してセキュリティサービスが適用されるEDI/ECコンテンツを交換するためのフォーマットとプロトコルにあります。
The "Secure Transmission Loop" (STL) comprises the following two steps:
「セキュアトランスミッションループ」（STL）は、次の2つのステップで構成されています。
a) The originator sends a signed and encrypted document with a request for a signed receipt.
a) オリジネーターは、署名済みの領収書を要求して、署名付きおよび暗号化されたドキュメントを送信します。
b) The recipient decrypts the document, verifies the signature, and returns a signed receipt to the sender.
b) 受信者はドキュメントを復号化し、署名を検証し、送信者に署名された領収書を返します。
In other words, the following events occur during the execution of the STL:
言い換えれば、STLの実行中に次のイベントが発生します。
- The organization sending EDI/EC data signs and encrypts the data using S/MIME. In addition, the message will request a signed receipt to be returned to the sender of the message.
- S/MIMEを使用してEDI/ECデータサインを送信し、データを暗号化する組織。さらに、メッセージは、署名入りの領収書を要求して、メッセージの送信者に返送されます。
- The receiving organization decrypts the message and verifies the signature, resulting in verified integrity of the data and authenticity of the sender.
- 受信組織はメッセージを復号化し、署名を検証し、その結果、データの整合性と送信者の信頼性が確認されます。
- The receiving organization then returns a signed receipt, as requested to the sending organization in the form of a message disposition notification. This signed receipt will contain the hash of the signature from the received message, indicating to the sender that the received message was verified and/or decrypted properly.
- その後、受信組織は、メッセージ処分通知の形で送信組織に要求されたように、署名済みの領収書を返します。この署名済みの領収書には、受信したメッセージからの署名のハッシュが含まれ、受信したメッセージが検証されているか、適切に復号化されたことを送信者に示します。
The above describes functionality that, if implemented, will satisfy all security requirements and provide non-repudiation of receipt for the exchange. While trading partners will usually want to utilize the STL, this specification does not require it.
上記は、実装された場合、すべてのセキュリティ要件を満たし、取引所の領収書の控除を提供する機能について説明しています。通常、トレーディングパートナーはSTLを利用したいと思うでしょうが、この仕様ではそれを必要としません。
The term used for both the functional activity and the message for acknowledging delivery of an EDI/EC interchange is "receipt" or "signed receipt". The term receipt is used if the acknowledgment is for an interchange resulting in a receipt that is NOT signed. The term signed receipt is used if the acknowledgment is for an interchange resulting in a receipt that IS signed. A term often used in combination with receipts is non-repudiation of receipt. NRR refers to a legal event that occurs only when the original sender of an interchange has verified the signed receipt coming back from the recipient of the message. Note that NRR is not possible without signatures.
機能的活動とEDI/ECインターチェンジの配信を認めるためのメッセージの両方に使用される用語は、「領収書」または「署名領収書」です。領収書は、署名されていない領収書になったインターチェンジ用の承認がある場合に使用されます。署名された領収書は、署名された領収書を介して交換を行うための承認が行われた場合に使用されます。領収書と組み合わせてよく使用される用語は、領収書の非和解です。NRRは、インターチェンジの元の送信者がメッセージの受信者から戻ってくる署名領収書を確認した場合にのみ発生する法的イベントを指します。NRRは署名なしでは不可能であることに注意してください。
For additional information on formatting and processing receipts in AS3, refer to Section 7.
AS3の領収書のフォーマットと処理の追加情報については、セクション7を参照してください。
- Encrypted object is an EDI/EC Interchange.
- 暗号化されたオブジェクトは、EDI/ECインターチェンジです。
This specification assumes that a typical EDI/EC interchange is the lowest level object that will be subject to the application of security services.
この仕様は、典型的なEDI/ECインターチェンジがセキュリティサービスの適用の対象となる最低レベルのオブジェクトであると想定しています。
Specifically, for EDI ANSI X12, the entire document (including the ISA and IEA segments) is the atom to which security is applied. For EDIFACT, the corresponding definition includes the segments UNA/UNB and UNZ. In other words, EDI/EC interchanges including envelope segments remain intact and unreadable during secure transport.
具体的には、EDI ANSI X12の場合、ドキュメント全体（ISAおよびIEAセグメントを含む）は、セキュリティが適用される原子です。edifactの場合、対応する定義には、una/unbとunzのセグメントが含まれます。言い換えれば、エンベロープセグメントを含むEDI/ECインターチェンジは、安全な輸送中はそのままで読めないままです。
- EDI envelope headers are encrypted.
- EDIエンベロープヘッダーは暗号化されています。
Congruent with the above statement, EDI envelope headers are NOT visible in the MIME package. In order to optimize routing from existing commercial EDI networks (called Value Added Networks or VANs) to the Internet, work may need to be done in the future to define ways to extract some elements of the envelope to make them visible; however, that is beyond the scope of this specification.
上記の声明と一致して、EDIエンベロープヘッダーはMIMEパッケージには見えません。既存の商用EDIネットワーク（付加価値ネットワークまたはバンと呼ばれる）からインターネットへのルーティングを最適化するには、エンベロープのいくつかの要素を抽出して見えるようにする方法を定義するために、将来作業を行う必要がある場合があります。ただし、これはこの仕様の範囲を超えています。
- X12.58 and UN/EDIFACT security considerations
- X12.58およびUN/EDIFACTセキュリティに関する考慮事項
The most common EDI standards bodies, ANSI X12 and EDIFACT, have defined internal provisions for security. X12.58 is the security mechanism for ANSI X12, and AUTACK provides security for EDIFACT. This specification DOES NOT dictate use or non-use of these security standards. They are both fully compatible, though possibly redundant, with this specification.
最も一般的なEDI標準団体であるANSI X12およびEDIFACTは、セキュリティに関する内部規定を定義しています。X12.58はANSI X12のセキュリティメカニズムであり、Autackはエディファクトのセキュリティを提供します。この仕様は、これらのセキュリティ基準の使用または不使用を決定するものではありません。これらは両方とも、この仕様とは冗長性であるかもしれませんが、完全に互換性があります。
- Encrypted or un-encrypted data
- 暗号化または暗号化されていないデータ
This specification allows for EDI/EC message exchange where the EDI/EC data can be either un-protected or protected by means of encryption.
この仕様により、EDI/ECデータが暗号化によって保護されていないか、保護されているEDI/ECメッセージ交換が可能になります。
- Signed or unsigned data
- 署名または署名されていないデータ
This specification allows for EDI/EC message exchange with or without digital signature of the original EDI transmission.
この仕様により、元のEDI送信のデジタル署名の有無にかかわらず、EDI/ECメッセージ交換が可能になります。
- Use of receipt or not
- 領収書の使用かどうか
This specification allows for EDI/EC message transmission with or without a request for receipt notification. If a signed receipt notification is requested, however, a MIC value is REQUIRED as part of the returned receipt, unless an error condition occurs that results in the inability to compute a valid digest. (Such a case would result, for instance, if an encrypted message could not be decrypted.) Under such circumstances, an unsigned receipt (MDN) SHOULD be returned with the correct "disposition modifier" error value.
この仕様により、領収書通知のリクエストの有無にかかわらず、EDI/ECメッセージ送信が可能になります。ただし、署名された領収書通知が要求された場合、有効なダイジェストを計算できないエラー条件が発生しない限り、返された領収書の一部としてマイク値が必要です。（たとえば、このようなケースは、暗号化されたメッセージを復号化できなかった場合に発生します。）そのような状況では、正しい「処分修飾子」エラー値で署名されていない領収書（MDN）を返す必要があります。
- Security formatting
- セキュリティフォーマット
This specification relies on the guidelines set forth in RFCs 3852 [9] and 3851 [10]. The first of these RFCs describes the Cryptographic Message Syntax (CMS), and the second contains the S/MIME Version 3.1 Message Specification describing a MIME container for CMS objects. Whenever the term S/MIME is used in this document, it refers to Version 3.1 as described therein.
この仕様は、RFCS 3852 [9]および3851 [10]に記載されているガイドラインに依存しています。これらのRFCの最初のものは、暗号化メッセージの構文（CMS）を記述し、2番目にはCMSオブジェクトのMIMEコンテナを説明するS/MIMEバージョン3.1メッセージ仕様が含まれています。このドキュメントでは、S/MIMEという用語が使用されるときはいつでも、そこに記載されているバージョン3.1を指します。
- Hash function, message digest choices
- ハッシュ関数、メッセージダイジェストの選択
When a signature is used, it is RECOMMENDED that the SHA-1 hash algorithm be used for all outgoing messages; however, both MD5 and SHA-1 MUST be supported for incoming messages.
署名を使用する場合、すべての発信メッセージにSHA-1ハッシュアルゴリズムを使用することをお勧めします。ただし、受信メッセージのMD5とSHA-1の両方をサポートする必要があります。
- Permutation summary
- 順列の概要
In summary, the following twelve security permutations are possible in any given trading relationship:
要約すると、特定の取引関係で次の12のセキュリティ順列が可能です。
1. Sender sends un-encrypted data, does NOT request a receipt.
1. 送信者は、暗号化されていないデータを送信し、領収書を要求しません。
2. Sender sends un-encrypted data, requests an unsigned receipt. The receiver sends back the unsigned receipt.
2. 送信者は、暗号化されていないデータを送信し、署名されていない領収書を要求します。受信者は、署名されていない領収書を送り返します。
3. Sender sends un-encrypted data, requests a signed receipt. The receiver sends back the signed receipt.
3. 送信者は、暗号化されていないデータを送信し、署名された領収書を要求します。受信者は、署名された領収書を送り返します。
4. Sender sends encrypted data, does NOT request a receipt.
4. 送信者は暗号化されたデータを送信し、領収書を要求しません。
5. Sender sends encrypted data, requests an unsigned receipt. The receiver sends back the unsigned receipt.
5. 送信者は暗号化されたデータを送信し、署名されていない領収書を要求します。受信者は、署名されていない領収書を送り返します。
6. Sender sends encrypted data, requests a signed receipt. The receiver sends back the signed receipt.
6. 送信者は暗号化されたデータを送信し、署名された領収書を要求します。受信者は、署名された領収書を送り返します。
7. Sender sends signed data, does NOT request a receipt.
7. 送信者は署名されたデータを送信し、領収書を要求しません。
8. Sender sends signed data, requests an unsigned receipt. Receiver sends back the unsigned receipt.
8. 送信者は署名されたデータを送信し、署名されていない領収書を要求します。レシーバーは、署名されていない領収書を送り返します。
9. Sender sends signed data, requests a signed receipt. Receiver sends back the signed receipt.
9. 送信者は署名されたデータを送信し、署名された領収書を要求します。レシーバーは署名された領収書を送り返します。
10. Sender sends encrypted and signed data, does NOT request a receipt.
10. 送信者は暗号化されたデータと署名データを送信し、領収書を要求しません。
11. Sender sends encrypted and signed data, requests an unsigned receipt. Receiver sends back the unsigned receipt.
11. 送信者は暗号化されたデータと署名データを送信し、署名されていない領収書を要求します。レシーバーは、署名されていない領収書を送り返します。
12. Sender sends encrypted and signed data, requests a signed receipt. Receiver sends back the signed receipt. This case represents the Secure Transmission Loop described above.
12. 送信者は暗号化されたデータと署名されたデータを送信し、署名された領収書を要求します。レシーバーは署名された領収書を送り返します。このケースは、上記の安全な伝送ループを表しています。
The AS3 specification supports compression of transmitted data directly through the application of RFC 3274. Implementation details may be found in that RFC and in Harding's document, "Compressed Data for EDIINT".
AS3仕様は、RFC 3274の適用を通じて送信データの圧縮をサポートします。実装の詳細は、そのRFCおよびHardingの文書「EDIINTの圧縮データ」に記載されている場合があります。
RFC 959 specifies how data is transferred using the File Transfer Protocol (FTP)
RFC 959は、ファイル転送プロトコル（FTP）を使用してデータの転送方法を指定します
This RFC describes a framework for providing security services to FTP.
このRFCは、FTPにセキュリティサービスを提供するためのフレームワークについて説明しています。
This document defines security multiparts for MIME: multipart/encrypted and multipart/signed.
このドキュメントでは、MIMEのセキュリティマルチパート：MultiPART/暗号化およびマルチパート/署名を定義しています。
RFC 3462 defines the use of the multipart/report content type, upon which RFC 3798 builds to define the Message Disposition Notification.
RFC 3462は、MultiPart/Reportコンテンツタイプの使用を定義します。RFC3798は、メッセージ処分通知を定義するために構築します。
This RFC defines the use of content type "application" for ANSI X12 (application/EDI-X12), EDIFACT (application/EDIFACT), and mutually defined EDI (application/EDI-Consent).
このRFCは、ANSI X12（Application/EDI-X12）、Edifact（Application/Edifact）、および相互に定義されたEDI（Application/EDI-Consent）のコンテンツタイプ「アプリケーション」の使用を定義します。
These are the basic MIME standards, upon which all MIME-related RFCs build, including this one. Key contributions include definitions of "content type", "sub-type", and "multipart", as well as encoding guidelines, which establish 7-bit US-ASCII as the canonical character set to be used in Internet messaging.
これらは基本的なMIME標準であり、これを含むすべてのMIME関連RFCが構築されています。重要な貢献には、「コンテンツタイプ」、「サブタイプ」、「マルチパート」の定義、およびインターネットメッセージングで使用される標準文字セットとして7ビットのUS-ASCIIを確立するエンコードガイドラインが含まれます。
This Internet RFC defines how a Message Disposition Notification (MDN)is requested, as well as the format and syntax of the MDN. The MDN is the vehicle used by this specification to provide both signed and unsigned receipts.
このインターネットRFCは、MDNの形式と構文だけでなく、メッセージ処分通知（MDN）の要求方法を定義します。MDNは、この仕様で使用される車両であり、署名された領収書と署名されていない領収書の両方を提供します。
This specification describes how MIME shall carry Cryptographic Message Syntax (CMS) Objects.
この仕様では、MIMEが暗号化メッセージの構文（CMS）オブジェクトをどのように運ぶかについて説明します。
RFC 3850 describes certificate handling in the context of CMS and S/MIME.
RFC 3850は、CMSおよびS/MIMEのコンテキストでの証明書処理について説明しています。
This specification provides a mechanism to wrap compressed data within a CMS object.
この仕様は、CMSオブジェクト内で圧縮データをラップするメカニズムを提供します。
This RFC defines the use of content type "application" for XML. Note that while conforming implementations SHOULD support the expanded syntax that RFC 3023 introduces for the "+xml" suffix, no support for external parsed entity types is anticipated (as it adds significant complexity to signature processing).
このRFCは、XMLのコンテンツタイプ「アプリケーション」の使用を定義します。適合実装は、RFC 3023が「XML」接尾辞に導入する拡張構文をサポートする必要があるが、外部解析エンティティタイプのサポートは予想されない（署名処理に大きな複雑さを追加するため）。
The basic structure of AS3 messages comprises MIME encapsulated data with both customary MIME headers and a few additional AS3-specific outer headers. The structures below are described hierarchically in terms of which RFCs have been applied to form the specific structure. The reader is referred directly to the referenced RFCs for implementation details.
AS3メッセージの基本構造は、慣習的なMIMEヘッダーといくつかの追加のAS3固有の外側ヘッダーの両方を備えたMIMEカプセル化データで構成されています。以下の構造は、RFCが特定の構造を形成するために適用されているという点で階層的に説明されています。読者は、実装の詳細については、参照されたRFCSに直接紹介されます。
Any additional restrictions imposed by this AS are specifically discussed in the sections that follow.
これによって課される追加の制限は、以下のセクションで具体的に説明されています。
No encryption, no signature
暗号化も署名もありません
-RFC822/2045 -RFC1767/RFC2376 (application/EDIxxxx or /xml)
-RFC822/2045 -RFC1767/RFC2376（Application/Edixxxxまたは/xml）
No encryption, signature
暗号化なし、署名
-RFC822/2045
-RFC1847 (multipart/signed)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)
-RFC3851 (application/pkcs7-signature)
Encryption, no signature
暗号化、署名なし
-RFC822/2045
-RFC3851 (application/pkcs7-mime)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
Encryption, signature
暗号化、署名
-RFC822/2045
-RFC3851 (application/pkcs7-mime)
-RFC1847 (multipart/signed)(encrypted)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
-RFC3851 (application/pkcs7-signature)(encrypted)
MDN, no signature
MDN、署名なし
-RFC822/2045 -RFC3798 (message/disposition-notification)
-RFC822/2045 -RFC3798（メッセージ/処分 - 解釈）
MDN, signature
MDN、署名
-RFC822/2045 -RFC1847 (multipart/signed) -RFC3798 (message/disposition-notification) -RFC3851 (application/pkcs7-signature)
-RFC822/2045 -RFC1847（MultiPart/Signed）-RFC3798（Message/Dais -Notification）-RFC3851（Application/PKCS7 -Signature）
While all MIME content types SHOULD be supported, the following MIME content types MUST be supported:
すべてのMIMEコンテンツタイプをサポートする必要がありますが、次のMIMEコンテンツタイプをサポートする必要があります。
Content-Type: multipart/signed
Content-Type: multipart/report
Content-type: message/disposition-notification
Content-Type: application/PKCS7-signature
Content-Type: application/PKCS7-mime
Content-Type: application/EDI-X12
Content-Type: application/EDIFACT
Content-Type: application/edi-consent
Content-Type: application/XML
The AS3-From and AS3-To headers have been provided to assist the sender and the recipient of an EC document to identify each other:
AS3-FROMおよびAS3-to-to-to-to-toは、送信者とECドキュメントの受信者がお互いを識別するのを支援するために提供されています。
AS3-From: < AS3-name >
AS3-To: < AS3-name >
These headers contain textual values, described by the ABNF [22] below, identifying the sender/receiver of a data exchange. A value may be company specific (e.g., a Data Universal Numbering System (DUNS) number), or it may be simply some string mutually acceptable to both trading partners used to identify each to the other.
これらのヘッダーには、以下のABNF [22]で説明されているテキスト値が含まれており、データ交換の送信者/受信機を識別します。値は、企業固有のもの（例：データユニバーサル番号システム（DUNS）番号など）である場合があります。または、それぞれを識別するために使用される取引パートナーの両方に相互に受け入れられる文字列である場合があります。
AS3-text = "!" / ; printable ASCII characters
%d35-91 / ; except double-quote (%d34)
%d93-126 ; or backslash (%d92)
AS3-qtext = AS3-text / SP ; allow space only in quoted text
AS3-quoted-pair = "\" DQUOTE / ; \" or
"\" "\" ; \\
AS3-quoted-name = DQUOTE 1*128( AS3-qtext /
AS3-quoted-pair) DQUOTE
AS3-atomic-name = 1*128AS3-text
AS3-name = AS3-atomic-name / AS3-quoted-name
Note: SP and DQUOTE are defined in [ABNF]RFC 4234.
注：SPとDquoteは[ABNF] RFC 4234で定義されています。
The AS3-From header value and the AS3-To header value MUST each be an AS3-name comprising 1 to 128 printable ASCII characters. The header MUST NOT be folded, and the value for each of these headers is case-sensitive.
AS3-Fromヘッダー値とAS3からヘッダー値は、それぞれ1〜128の印刷可能なASCII文字を含むAS3-Nameでなければなりません。ヘッダーを折りたたむべきではなく、これらのヘッダーのそれぞれの値はケースに敏感です。
The AS3-quoted-name SHOULD be used only if the AS3-name does not conform to AS3-atomic-name.
AS3-quoted-nameは、AS3-NameがAS3原子名に準拠していない場合にのみ使用する必要があります。
The AS3-To and AS3-From header fields MUST be present in all AS3 messages and AS3 MDNs.
AS3-toおよびAS3-fromヘッダーフィールドは、すべてのAS3メッセージおよびAS3 MDNに存在する必要があります。
Implementations that map entities such as EDI identifiers/qualifiers to AS3 identifiers may choose to constrain the set of AS3-To/AS3-From text values to a subset of the full set defined above, but they may not extend that set.
Implementations that map entities such as EDI identifiers/qualifiers to AS3 identifiers may choose to constrain the set of AS3-To/AS3-From text values to a subset of the full set defined above, but they may not extend that set.
If the AS3-From or the AS3-To or the association of the two header values is determined to be invalid or unknown to the receiving system, the receiving system MAY respond with an unsigned MDN containing an explanation of the error if the sending system requested an MDN, but it is not required to return an MDN under those circumstances.
AS3-FROMまたはAS3-toまたは2つのヘッダー値の関連性が受信システムに無効または不明であると判断された場合、受信システムは、送信システムが要求された場合、エラーの説明を含む署名されていないMDNで応答する場合がありますMDNですが、そのような状況下でMDNを返す必要はありません。
The AS3-Version header is a header that is required only if the value of the header is not "1.0". Its purpose is to allow systems to determine which version of this specification (should the specification evolve over time) the sender of a document has used to package the document. A user agent MUST NOT reject a message if the version header is missing.
AS3-versionヘッダーは、ヘッダーの値が「1.0」でない場合にのみ必要なヘッダーです。その目的は、システムのどのバージョンがこの仕様（仕様が進化する必要があるか）を決定できるようにすることです。ドキュメントの送信者がドキュメントのパッケージ化に使用しています。バージョンヘッダーが欠落している場合、ユーザーエージェントはメッセージを拒否してはなりません。
AS3-Version: 1*DIGIT . 1*DIGIT
A version header value of "1.1" indicates an implementation can support EDIINT data compression [20]. A user agent MUST NOT send compressed messages to trading partners who do not use a version header of "1.1" or greater.
「1.1」のバージョンヘッダー値は、実装がEDIINTデータ圧縮をサポートできることを示します[20]。ユーザーエージェントは、「1.1」以上のバージョンヘッダーを使用しないトレーディングパートナーに圧縮メッセージを送信してはなりません。
FTP has long been viewed as an insecure protocol primarily because of its use of cleartext authentication [3]. This is addressed by RFC 2228 [4], and the use of one of the security mechanisms described therein is strongly encouraged. Specifically, conforming implementations of AS3 SHALL employ FTP client/servers that support the AUTH command described within [4]. While any authentication mechanism based upon [4] MAY be utilized, AUTH TLS (as described in [18]) MUST be supported. (Note that [18] relies on TLS Version 1.0 [13], not Version 1.1 [23].)
FTPは、主にClearText認証の使用により、長い間不安定なプロトコルと見なされてきました[3]。これはRFC 2228 [4]によって対処されており、そこに記載されているセキュリティメカニズムの1つの使用が強く奨励されています。具体的には、AS3の適合実装は、[4]内で説明されている認証コマンドをサポートするFTPクライアント/サーバーを使用するものとします。[4]に基づく認証メカニズムを利用することができますが、認証TLS（[18]で説明されている）をサポートする必要があります。（[18]は、バージョン1.1 [23]ではなく、TLSバージョン1.0 [13]に依存していることに注意してください。）
Large files are handled correctly by the TCP layer. However, the mechanism for compressing data, referenced in Section 2.4.2.2, efficiently reduces transmission requirements for many data types (including both XML and traditional EDI data). Additionally, some FTP implementations support compression as well.
大きなファイルは、TCPレイヤーによって正しく処理されます。ただし、セクション2.4.2.2で参照されているデータを圧縮するメカニズムは、多くのデータ型（XMLと従来のEDIデータの両方を含む）の伝送要件を効率的に削減します。さらに、一部のFTP実装も圧縮をサポートしています。
An AS3 message MUST contain the following outer headers:
AS3メッセージには、次の外側ヘッダーが含まれている必要があります。
AS3-To AS3-From Date Message-ID Content-Type
AS3-to AS3-from Date Message-IDコンテンツタイプ
An AS3 message OPTIONALLY MAY contain the following outer headers:
Optional AS3メッセージには、次の外側ヘッダーが含まれている場合があります。
Subject AS3-Version (assumed to be 1.0 if not present) Content-Length
被験者AS3-version（存在しない場合は1.0と想定）コンテンツレングス
An AS3 message requesting a receipt MUST contain a Disposition-Notification-To header and MAY contain a Disposition-Notification-Options header (if the receipt is to be signed).
領収書を要求するAS3メッセージには、処分解釈へのヘッダーが含まれている必要があり、処分 - 解釈オプションヘッダー（領収書が署名される場合）を含めることができます。
Additional headers MAY be present but are ignored.
追加のヘッダーが存在する場合がありますが、無視されます。
FTP defines several data structures and character encodings via the STRU[cture] and TYPE commands. AS3 requires the file-structure (default) and the image type. The Content-Transfer-Encoding header SHOULD NOT be used; if the header is present, it SHOULD have a value of binary or 8-bit. The absence of this header or the use of alternate values such as "base64" or "quoted-printable" MUST NOT result in transaction failure. Content transfer encoding of MIME parts within the AS3 message are similarly constrained.
FTPは、stru [cuter]およびタイプコマンドを介していくつかのデータ構造と文字エンコーディングを定義します。AS3には、ファイル構造（デフォルト）と画像タイプが必要です。コンテンツトランスファーエンコードヘッダーは使用しないでください。ヘッダーが存在する場合、バイナリまたは8ビットの値が必要です。このヘッダーがない場合、または「base64」や「引用符で囲まれた」などの代替値の使用は、トランザクションの障害をもたらさないはずです。AS3メッセージ内のMIME部品のコンテンツ転送エンコードも同様に制約されます。
A MIME message containing an epilogue [1] SHALL NOT be used.
エピローグ[1]を含むMIMEメッセージは使用してはなりません。
Message-Id and Original-Message-Id are formatted as defined in Section 3.6.4 of RFC 2822 [15]: "<" id-left "@" id-right ">". Message-Id length is a maximum of 998 characters. Message-Id SHOULD be globally unique; id-right should be something unique to the sending host environment (e.g., a host name). When sending a message, always include the angle brackets. Angle brackets are not part of the Message-Id value.
Message-IDおよびOriginal-Message-IDは、RFC 2822 [15]のセクション3.6.4で定義されているようにフォーマットされています。メッセージ-IDの長さは最大998文字です。メッセージ-IDはグローバルに一意である必要があります。ID-rightは、送信ホスト環境（ホスト名など）に固有のものである必要があります。メッセージを送信するときは、常に角度ブラケットを含めます。角度ブラケットは、メッセージ-ID値の一部ではありません。
NOTE: When creating the Original-Message-Id header in an MDN, always use the exact syntax contained in the original message: do not strip or add "angle brackets".
注：MDNで元のMessage-IDヘッダーを作成する場合、元のメッセージに含まれる正確な構文を常に使用します。「角度ブラケット」を剥がしたり、追加したりしないでください。
In order to support non-repudiation of receipt, a signed receipt, based on digitally signing a message disposition notification, is to be implemented by a receiving trading partner's UA. The message disposition notification specified by RFC 3798 is digitally signed by a receiving trading partner as part of a multipart/signed MIME message.
領収書の非控除をサポートするために、メッセージ処分通知へのデジタル署名に基づく署名済みの領収書は、受信トレーディングパートナーのUAによって実装されます。RFC 3798によって指定されたメッセージ処分通知は、マルチパート/署名されたMIMEメッセージの一部として受信トレーディングパートナーによってデジタル署名されています。
The following support for signed receipts is REQUIRED:
署名された領収書の次のサポートが必要です。
1) The ability to create a multipart/report; where the report-type = disposition-notification.
1) マルチパート/レポートを作成する機能。ここで、レポート-Type =処分 - 解釈。
2) The ability to calculate a message integrity check (MIC) on the received message. The calculated MIC value will be returned to the sender of the message inside the signed receipt.
2) 受信したメッセージでメッセージ整合性チェック（MIC）を計算する機能。計算されたマイク値は、署名された領収書内のメッセージの送信者に返されます。
3) The ability to create a multipart/signed content with the message disposition notification as the first body part, and the signature as the second body part.
3) メッセージ処分通知を使用して、最初のボディパーツとしてのマルチパート/署名コンテンツを作成する機能、および2番目のボディパートとしての署名。
4) The ability to return the signed receipt to the sending trading partner.
4) 署名された領収書を送信貿易相手パートナーに返却する機能。
The signed receipt is used to notify a sending trading partner that requested the signed receipt that:
署名された領収書は、署名された領収書に次のように要求した送信貿易相手のパートナーに通知するために使用されます。
1) The receiving trading partner acknowledges receipt of the sent EC Interchange.
1) 受信トレーディングパートナーは、送信されたECインターチェンジの受領を認めています。
2) If the sent message was signed, then the receiving trading partner has authenticated the sender of the EC Interchange.
2) 送信されたメッセージに署名された場合、受信トレーディングパートナーはECインターチェンジの送信者を認証しました。
3) If the sent message was signed, then the receiving trading partner has verified the integrity of the sent EC Interchange.
3) 送信されたメッセージに署名された場合、受信トレーディングパートナーは送信されたECインターチェンジの完全性を確認しました。
Regardless of whether the EDI/EC Interchange was sent in S/MIME format or not, the receiving trading partner's UA MUST provide the following basic processing:
EDI/ECインターチェンジがS/MIME形式で送信されたかどうかに関係なく、受信トレーディングパートナーのUAは次の基本処理を提供する必要があります。
1) If the sent EDI/EC Interchange is encrypted, then the encrypted symmetric key, and initialization vector (if applicable) is decrypted using the receiver's private key.
1) 送信されたEDI/ECインターチェンジが暗号化されている場合、暗号化された対称キーと初期化ベクトル（該当する場合）は、受信機の秘密キーを使用して復号化されます。
2) The decrypted symmetric encryption key is then used to decrypt the EDI/EC Interchange.
2) 次に、復号化された対称暗号化キーを使用して、EDI/ECインターチェンジを復号化します。
3) The receiving trading partner authenticates signatures in a message using the sender's public key.
3) 受信トレーディングパートナーは、送信者の公開キーを使用してメッセージ内の署名を認証します。
The authentication algorithm performs the following:
認証アルゴリズムは次のことを実行します。
a) The message integrity check (MIC or Message Digest) is decrypted using the sender's public key.
a) メッセージの整合性チェック（マイクまたはメッセージダイジェスト）は、送信者の公開キーを使用して復号化されます。
b) A MIC on the signed contents (the MIME header and encoded EDI object, as per RFC 1767) in the message received is calculated using the same one-way hash function that the sending trading partner used.
b) 受信したメッセージの署名されたコンテンツのマイク（MIMEヘッダーとエンコードされたEDIオブジェクト、RFC 1767に従って）は、送信する取引パートナーが使用したのと同じ一方向ハッシュ関数を使用して計算されます。
c) The MIC extracted from the message that was sent and the MIC calculated using the same one-way hash function that the sending trading partner used are compared for equality.
c) 送信されたメッセージから抽出されたマイクと、送信する取引パートナーが使用したのと同じ一方向ハッシュ関数を使用してMICが計算されます。
4) The receiving trading partner formats the MDN and sets the calculated MIC into the "Received-content-MIC" extension field.
4) 受信トレーディングパートナーはMDNをフォーマットし、計算されたマイクを「受信コンテンツマイク」拡張フィールドに設定します。
5) The receiving trading partner creates a multipart/signed MIME message according to RFC 1847.
5) 受信トレーディングパートナーは、RFC 1847に従ってマルチパート/署名されたMIMEメッセージを作成します。
6) The MDN is the first part of the multipart/signed message, and the digital signature is created over this MDN, including its MIME headers.
6) MDNはMultiPart/署名されたメッセージの最初の部分であり、MIMEヘッダーを含むこのMDNにデジタル署名が作成されます。
7) The second part of the multipart/signed message contains the digital signature. The "protocol" option specified in the second part of the multipart/signed is as follows: S/MIME: protocol = "application/pkcs7-signature".
7) MultiPart/署名されたメッセージの2番目の部分には、デジタル署名が含まれています。MultiPart/Signedの2番目の部分で指定された「プロトコル」オプションは、次のとおりです。S/MIME：Protocol = "Application/PKCS7-Signature"。
8) The signature information is formatted according to S/MIME specifications. The EC Interchange and the RFC 1767 MIME EDI content header can actually be part of a multipart MIME content type. When the EDI Interchange is part of a multipart MIME content type, the MIC MUST be calculated across the entire multipart content, including the MIME headers.
8) 署名情報は、S/MIME仕様に従ってフォーマットされます。ECインターチェンジとRFC 1767 MIME EDIコンテンツヘッダーは、実際にはマルチパートMIMEコンテンツタイプの一部になります。EDIインターチェンジがマルチパートMIMEコンテンツタイプの一部である場合、MIMEヘッダーを含むマルチパートコンテンツ全体でマイクを計算する必要があります。
The signed MDN, when received by the sender of the EDI Interchange can be used by the sender:
EDIインターチェンジの送信者が受信した場合、署名されたMDNは、送信者が使用できます。
1) As an acknowledgment that the EDI Interchange was sent, and then was delivered and acknowledged by the receiving trading partner.
1) EDIインターチェンジが送信され、その後、受信トレーディングパートナーによって配信され、承認されたという承認として。
The receiver does this by returning the original-message-id of the sent message in the MDN portion of the signed receipt.
受信者は、署名された領収書のMDN部分に送信されたメッセージの元のメッセージ-IDを返すことにより、これを行います。
2) As an acknowledgment that the integrity of the EDI Interchange was verified by the receiving trading partner. The receiver does this by returning the calculated MIC of the received EC Interchange (and 1767 MIME headers) in the "Received-content-MIC" field of the signed MDN.
2) EDIインターチェンジの完全性が受信トレーディングパートナーによって検証されたという認識として。受信者は、署名されたMDNの「受信コンテンツマイック」フィールドで受信したECインターチェンジ（および1767 MIMEヘッダー）の計算マイクを返すことにより、これを行います。
3) As an acknowledgment that the receiving trading partner has authenticated the sender of the EDI Interchange.
3) 受信トレーディングパートナーがEDIインターチェンジの送信者を認証したという認識として。
4) As a non-repudiation of receipt when the signed MDN is successfully verified by the sender with the receiving trading partner's public key and the returned MIC value inside the MDN is the same as the digest of the original message.
4) 署名されたMDNが受信トレーディングパートナーの公開キーを使用して送信者によって正常に検証され、MDN内の返されたMIC値が元のメッセージのダイジェストと同じです。
The AS3-MDNs are returned on a separate FTP TCP/IP connection and are a response to an AS3 message.
AS3-MDNSは別のFTP TCP/IP接続で返され、AS3メッセージへの応答です。
The following diagram illustrates the delivery of an AS3-MDN delivery:
次の図は、AS3-MDN配信の配信を示しています。
AS3-MDN
[S] ----( connect )----> [R] [FTP Server]
[S] ----( send )-------> [R] [AS3-Message]
[S] ----( disconnect )-> [R] [FTP Server]
[S] <---( connect )----- [R] [FTP Server]
[S] <---( send )-------- [R] [AS3-MDN]]
[S] <---( disconnect )-- [R] [FTP Server]
Note: Refer to Section 7.4.4 for additional programming notes.
注：追加のプログラミングノートについては、セクション7.4.4を参照してください。
Message Disposition Notifications are requested as per RFC 3798. A request that the receiving user agent issue a message disposition notification is made by placing the following header into the message to be sent:
メッセージ処分通知は、RFC 3798に従って要求されます。受信ユーザーエージェントがメッセージ処分通知を発行するというリクエストは、次のヘッダーをメッセージに配置することにより行われます。
MDN-request-header = "Disposition-notification-to" ":" ftpurl
This syntax is a residual of the use of MDN's in an SMTP transfer. Since this specification is adjusting the functionality from SMTP to FTP and retaining as much as possible from the [5] functionality, the ftpurl must be present.
この構文は、SMTP転送でのMDNの使用の残留です。この仕様では、[5]機能から可能な限り機能を保持しているため、この仕様は[5]機能から可能な限り保持されるため、FTPURLが存在する必要があります。
The ftpurl field is specified as an RFC 1738 <URL:"ftp://" login [ "/" fpath [ ";type=" ftptype ]]>, and while it MUST be present, it may be ignored if the ftpurl points to an unknown location. If the ftpurl points to an unknown location, it is RECOMMENDED that the mdn is returned back to a known ftpurl for the sender of the received message.
ftpurlフィールドはRFC 1738 <url： "ftp：//" login ["/" fpath ["; type =" ftptype]]>として指定されており、存在する必要がありますが、ftpurlがポイントをポイントすると無視される場合があります。未知の場所へ。FTPURLが未知の場所を指している場合、受信したメッセージの送信者のMDNを既知のftpurlに戻すことをお勧めします。
For requesting MDN-based receipts, the originator supplies the required extension headers that precede the message body.
MDNベースの領収書を要求するために、オリジネーターはメッセージ本文の前に必要な拡張ヘッダーを提供します。
The header "tags" are as follows:
ヘッダー「タグ」は次のとおりです。
A Disposition-notification-to header is added to indicate that a message disposition notification is requested. This header is specified in [6].
処分 - notification-toヘッダーが追加されて、メッセージ処分通知が要求されていることを示します。このヘッダーは[6]で指定されています。
A Message-ID header is added to support message reconciliation, so that an Original-Message-Id value can be returned in the body part of the MDN.
メッセージの調整をサポートするためにメッセージ-IDヘッダーが追加され、MDNの本体部分で元のメッセージ-ID値を返すことができます。
Other headers, especially "Date", SHOULD be supplied; the values of these headers are often mentioned in the human-readable section of an MDN to aid in identifying the original message.
他のヘッダー、特に「日付」を提供する必要があります。これらのヘッダーの値は、元のメッセージの識別を支援するために、MDNの人間の読み取り可能なセクションでよく言及されています。
Disposition-notification-options identifies characteristics of the message.
気質 - 解決策は、メッセージの特性を識別します。
The following Disposition notification is in accordance with [6].
次の処分通知は[6]に準拠しています。
EXAMPLE:
Disposition-notification-to: // Requests the MDN
ftp://host:port/inbox // Location to return MDN
Disposition-notification-options: // The signing options for
MDN
signed-receipt-protocol=optional, pkcs7-signature;
signed-receipt-micalg=optional, sha1, md5
Disposition-notification-options syntax:
気質 - 解釈 - オプション構文：
Disposition-notification-options = "Disposition-Notification-Options:" disposition-notification-parameters
気質 - 節解決= "気質 - 節解決書："気質 - 節化 - パラメーター
disposition-notification-parameters =
parameter *(";" parameter)
parameter = attribute "=" importance ", " value *("," value)
importance = "required" / "optional"
attribute = "signed-receipt-protocol" / "signed-receipt-micalg"
So the Disposition-notification-options string could be:
したがって、気質 - notification-options文字列は次のとおりです。
signed-receipt-protocol=optional, <protocol symbol>;
signed-receipt-micalg=optional, <micalg1>, <micalg2>,...;
The currently supported value for <protocol symbol> is "pkcs7- signature" for the S/MIME detached signature format.
<プロトコルシンボル>の現在サポートされている値は、S/MIMEデタッチされた署名形式の「PKCS7-署名」です。
The currently supported values for MIC algorithm <micalg> values are:
マイクアルゴリズム<MICALG>値の現在サポートされている値は次のとおりです。
Algorithm Value
Used
-------- -------
MD5 md5
SHA-1 sha1
Receiving agents SHOULD be able to recover gracefully from a <micalg> parameter value that they do not recognize.
受信エージェントは、認識されていない<micalg>パラメーター値から優雅に回復できるはずです。
The semantics of the "signed-receipt-protocol" parameter is as follows:
「Signed-Receipt-Protocol」パラメーターのセマンティクスは次のとおりです。
1) The "signed-receipt-protocol" parameter is used to request a signed receipt from the recipient trading partner. The "signed-receipt-protocol" parameter also specifies the format in which the signed receipt should be returned to the requester.
1) 「Signed-Receipt-Protocol」パラメーターは、受信者取引パートナーに署名された領収書を要求するために使用されます。「Signed-Receipt-Protocol」パラメーターは、署名された領収書をリクエスターに返送する形式も指定します。
The "signed-receipt-micalg" parameter is a list of MIC algorithms preferred by the requester for use in signing the returned receipt and calculating the micalg in the Received-content-MIC header.
「Signed-Receipt-Micalg」パラメーターは、返された領収書に署名し、受信コンテンツMICヘッダーのMicalgを計算する際に使用するために要求者が好むマイクアルゴリズムのリストです。
The list of MIC algorithms should be honored by the recipient from left to right. Both the "signed-receipt-protocol" and the "signed-receipt-micalg" option parameters are REQUIRED when requesting a signed receipt.
マイクアルゴリズムのリストは、受信者が左から右に尊重する必要があります。署名済みの領収書を要求する際には、「署名されたReceipt-Protocol」と「Signed-Receipt-Micalg」オプションパラメーターの両方が必要です。
2) The "importance" attribute of "Optional" is defined in RFC 3798, Section 2.2, and has the following meaning:
2) 「オプション」の「重要性」属性は、RFC 3798、セクション2.2で定義されており、次の意味があります。
Parameters with an importance of "Optional" permit a UA that does not understand the particular options parameter to still generate an MDN in response to a request for an MDN. A UA that does not understand the "signed-receipt-protocol" parameter, or the "signed-receipt-micalg" parameter, will obviously not return a signed receipt.
「オプション」の重要性を持つパラメーターは、特定のオプションパラメーターを理解していないUAに、MDNのリクエストに応じてMDNを生成することを許可します。「Signed-Receipt-Protocol」パラメーター、または「Signed-Receipt-Micalg」パラメーターを理解していないUAは、明らかに署名された領収書を返さないでしょう。
The importance of "Optional" is used for the signed receipt parameters because it is RECOMMENDED that an MDN be returned to the requesting trading partner even if the recipient could not sign it.
「オプション」の重要性は、受信者が署名できなかったとしても、MDNを要求トレーディングパートナーに返すことをお勧めするため、署名された領収書パラメーターに使用されます。
The returned MDN will contain information on the disposition of the message as well as on why the MDN could not be signed. See the Disposition field in Section 7.5 for more information.
返されたMDNには、メッセージの処分と、MDNに署名できなかった理由に関する情報が含まれます。詳細については、セクション7.5の処分フィールドを参照してください。
Within an EDI trading relationship, if a signed receipt is expected and is not returned, then the validity of the transaction must be determined by the trading partners. Typically, if a signed receipt is required by the trading relationship and is not received, the transaction will likely not be considered valid.
EDI取引関係内で、署名された領収書が予想され、返されない場合、取引の有効性は取引パートナーによって決定されなければなりません。通常、署名された領収書が取引関係によって必要であり、受信されていない場合、取引は有効とは見なされない可能性があります。
The method used to request a receipt or a signed receipt is defined in RFC 3798, "An Extensible Message Format for Message Disposition Notifications".
領収書または署名済みの領収書をリクエストするために使用される方法は、RFC 3798「メッセージ処分通知の拡張可能なメッセージ形式」で定義されています。
The "rules" for processing a receipt-request follow:
領収書のリケストを処理するための「ルール」は次のとおりです。
1) When a receipt is requested, explicitly specifying that the receipt be signed, then the receipt MUST be returned with a signature unless conditions (2) or (3) below are applicable.
1) 領収書が要求された場合、領収書に署名されることを明示的に指定する場合、領収書は署名（2）または（3）が適用されない限り、署名で返品する必要があります。
2) When a receipt is requested, explicitly specifying that the receipt be signed, but the recipient cannot support either the requested protocol format, or requested MIC algorithms, then either a signed or unsigned receipt SHOULD be returned.
2) 領収書が要求された場合、領収書に署名されることを明示的に指定しますが、受信者は要求されたプロトコル形式、または要求されたマイクアルゴリズムのいずれかをサポートできません。その後、署名済みまたは署名されていない領収書を返品する必要があります。
3) When a receipt is requested, explicitly specifying that the receipt be signed, but the recipient is unable to compute the digest (e.g., message was encrypted, and recipient unable to decrypt), then the recipient SHOULD NOT return "Received-content-MIC" in the MDN to the requestor. If the MDN sets the disposition (e.g., "processed/error: decryption-failed") appropriately, then the "Received-content-MIC" may be returned, but the value must be discarded.
3) 領収書が要求された場合、領収書に署名されることを明示的に指定しますが、受信者はダイジェストを計算できません（例：メッセージは暗号化され、受信者は復号化できません）、受信者は「受信コンテンツマイク」を返してはなりません。MDNでリクエスターへ。MDNが処分（たとえば、「処理/エラー：復号化された」）を適切に設定する場合、「受信コンテンツマイク」を返すことができますが、値は破棄する必要があります。
4) When a signature is not explicitly requested, or if the signed receipt request parameter is not recognized by the UA, then no receipt, an unsigned receipt, or a signed receipt MAY be returned by the recipient.
4) 署名が明示的に要求されていない場合、または署名された領収書リクエストパラメーターがUAによって認識されない場合、領収書、署名されていない領収書、または署名済みの領収書を受信者が返品することができます。
5) If a message is received without a request for a receipt, then a receipt (signed or unsigned) MAY be returned.
5) 領収書のリクエストなしでメッセージが受信された場合、領収書（署名または署名なし）が返される場合があります。
The "Received-content-MIC" MUST be calculated as follows:
「受信コンテンツマイク」は次のように計算する必要があります。
- For any signed messages, the MIC to be returned is calculated on the RFC 1767 MIME header and content. Canonicalization as specified in RFC 1848 MUST be performed before the MIC is calculated, since the sender requesting the signed receipt was also REQUIRED to canonicalize.
- 署名されたメッセージの場合、返されるマイクはRFC 1767 MIMEヘッダーとコンテンツで計算されます。RFC 1848で指定されている正規化は、マイクが計算される前に実行する必要があります。これは、署名された領収書を要求する送信者も正規化するために必要であるためです。
- For encrypted, unsigned messages, the MIC to be returned is calculated on the decrypted RFC 1767 MIME header and content. The content after decryption MUST be canonicalized before the MIC is calculated.
- 暗号化された、署名されていないメッセージの場合、返されるマイクは、復号化されたRFC 1767 MIMEヘッダーとコンテンツで計算されます。復号化後のコンテンツは、マイクが計算される前に正規化する必要があります。
- For unsigned, un-encrypted messages, the MIC MUST be calculated over the message contents prior to Content-Transfer-Encoding and without the MIME or any other RFC 822 [14] headers, since these are sometimes altered or reordered by message transfer agents (MTAs).
- 署名されていない、暗号化されていないメッセージの場合、コンテンツ転送エンコードの前にメッセージコンテンツを介してマイクを計算する必要があります。mtas）。
This section defines the format of the AS3 Message Disposition Notification (AS3-MDN).
このセクションでは、AS3メッセージ処分通知（AS3-MDN）の形式を定義します。
The AS3-MDN follows the MDN specification [6] except where noted in this section. The modified entity definitions in this document use the vertical-bar character, '|', to denote a logical "OR" construction. Refer to RFC 2045 for the format of MIME-message-headers.
AS3-MDNは、このセクションに記載されている場合を除き、MDN仕様[6]に従います。このドキュメントの変更されたエンティティの定義は、論理的な「構造」または「構造」を示すために、垂直バー文字 '|'を使用します。Mime-Message-Headersの形式については、RFC 2045を参照してください。
The format of the AS3-MDN is
AS3-MDNの形式はです
MDN, no signature
MDN、署名なし
-RFC822/2045 -RFC3798 (message/disposition-notification)
-RFC822/2045 -RFC3798（メッセージ/処分 - 解釈）
MDN, signature
MDN、署名
-RFC822/2045 -RFC1847 (multipart/signed) -RFC3798 (message/disposition-notification) -RFC3851 (application/pkcs7-signature)
-RFC822/2045 -RFC1847（MultiPart/Signed）-RFC3798（Message/Dais -Notification）-RFC3851（Application/PKCS7 -Signature）
The AS3-MDN-body is formatted as a MIME multipart/report with a report-type of "disposition-notification".
AS3-MDN-Bodyは、「処分」のレポートタイプのMIMEマルチパート/レポートとしてフォーマットされています。
When unsigned, the transfer-layer ("outermost") entity-headers of the AS3-MDN contain the Content-Type header that specifies a content type of "multipart/report", parameters indicating the report-type, and the value of the outermost multipart boundary.
署名の場合、AS3-MDNのトランスファーレイヤー（「外側」）エンティティヘッダーには、コンテンツタイプの「マルチパート/レポート」、レポートタイプを示すパラメーター、および最も外側のマルチパート境界。
When the AS3-MDN is signed, the transfer-layer ("outermost") entity-headers of the AS3-MDN contain a Content-Type header that specifies a content type of "multipart/signed", parameters indicating the algorithm used to compute the message digest, the signature formatting protocol (e.g., pkcs7-signature), and the value of the outermost multipart boundary. The first part of the MIME multipart/signed message is an imbedded MIME multipart/report of type "disposition-notification". The second part of the multipart/signed message contains a MIME application/pkcs7-signature message.
AS3-MDNに署名された場合、AS3-MDNのトランスファーレイヤー（「外側」）エンティティヘッダーには、コンテンツタイプの「マルチパート/署名」を指定するコンテンツタイプのヘッダーが含まれています。メッセージダイジェスト、署名フォーマットプロトコル（例：PKCS7シグネチャ）、および最も外側のマルチパート境界の値。Mime MultiPart/署名されたメッセージの最初の部分は、「処分」タイプのMime MultiPart/レポートの埋め込みです。MultiPart/署名されたメッセージの2番目の部分には、MIMEアプリケーション/PKCS7シグネチャメッセージが含まれています。
The first part of the MIME multipart/report is a "human-readable" portion that contains a general description of the message disposition. The second part of the MIME multipart/report is a "machine-readable" portion that is defined as
MIME MultiPart/レポートの最初の部分は、メッセージ処分の一般的な説明を含む「人間が読める」部分です。Mime MultiPart/レポートの2番目の部分は、次のように定義される「機械可読」部分です
AS3-disposition-notification-content =
[ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ]
[ original-recipient-field CRLF ]
final-recipient-field CRLF
[ original-message-id-field CRLF ]
AS3-disposition-field CRLF
*( failure-field CRLF )
*( error-field CRLF )
*( warning-field CRLF )
*( extension-field CRLF )
[ AS3-received-content-MIC-field CRLF ]
It is noted that several of the optional fields defined by RFC 3798 and shown above are not relevant to a point-to-point transport such as FTP and would not normally appear in an AS3 MDN.
RFC 3798で定義され、上記に示すいくつかのオプションフィールドは、FTPなどのポイントツーポイントトランスポートには関係がなく、通常AS3 MDNには表示されないことに注意してください。
The rules for constructing the AS3-disposition-notification-content are identical to the rules for constructing the disposition-notification-content as defined in Section 7 of RFC 3798 [6] except that the RFC 3798 disposition-field has been replaced with the AS3- disposition-field and that the AS3-received-content-MIC field has been added. The differences between the RFC 3798 disposition-field and the AS3-disposition-field are described below. Where there are differences between this document and RFC 3798, those entity names have been changed by prepending "AS3-". Entities below that do not differ from RFC 3798 are not necessarily further defined in this document.
AS3-ディスポジション - ノティフィケーションコンテンツを構築するためのルールは、RFC 3798のセクション7で定義されているように、RFC 3798処分フィールドがAS3に置き換えられていることを除いて、気質 - ノティ化コンテンツを構築するためのルールと同一です。 - 処分場とAS3受容-Content-MICフィールドが追加されたこと。RFC 3798処分場とAS3拡散フィールドの違いを以下に説明します。このドキュメントとRFC 3798の間に違いがある場合、これらのエンティティ名は「AS3-」を準備することで変更されました。以下のエンティティは、RFC 3798と違いはありません。このドキュメントでは、必ずしもさらに定義されているわけではありません。
Refer to RFC 3798 [6] and RFC 4234 [22] for entities that are not further defined in this document.
このドキュメントでさらに定義されていないエンティティについては、RFC 3798 [6]およびRFC 4234 [22]を参照してください。
AS3-disposition-field = "Disposition:" disposition-mode ";" AS3-disposition-type [ "/" AS3-disposition-modifier]
AS3-Disposition-field = "処分："処分モード ";"AS3-Disposition-Type ["/" AS3-Disposition-Modifier]
disposition-mode = action-mode "/" sending-mode
処分モード=アクション - モード "/"送信モード
action-mode = "manual-action" / "automatic-action"
sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
AS3-disposition-type = "processed" / "failed"
AS3-disposition-modifier = ( "error" / "warning" ) /
AS3-disposition-modifier-extension
AS3-disposition-modifier-extension =
"error: authentication-failed" /
"error: decompression-failed" /
"error: decryption-failed" /
"error: insufficient-message-security" /
"error: integrity-check-failed" /
"error: unexpected-processing-error" /
"warning: " AS3-MDN-warning-description /
"failure: " AS3-MDN-failure-description
AS3-MDN-warning-description = *( TEXT )
AS3-MDN-failure-description = *( TEXT )
AS3-received-content-MIC-field = "Received-content-MIC:" encoded-message-digest "," digest-alg-id CRLF
AS3-RECEIVED-CONTENT-MIC-FIELD = "受信コンテンツマイク：" Encoded-message-digest "、" Digest-alg-id crlf
encoded-message-digest =
1*( ALPHA / DIGIT / "/" / "+" ) *3"="
;( i.e. base64( message-digest ) )
digest-alg-id = "sha1" / "md5"
The "Received-content-MIC" extension field is set after the integrity of the received message is verified. The MIC is the base64-encoded message-digest computed over the received message with a hash function. This field is required for signed receipts but optional for unsigned receipts. For details defining the specific content over which the message-digest is to be computed, see Section 7.3.1 of this document.
受信したメッセージの整合性が検証された後、「受信コンテンツマイク」拡張フィールドが設定されます。マイクは、ハッシュ関数を使用して受信したメッセージを介して計算されたbase64エンコードのメッセージダイジストです。このフィールドは、署名された領収書に必要ですが、署名されていない領収書にはオプションです。詳細については、メッセージダイジェストを計算する特定のコンテンツを定義するには、このドキュメントのセクション7.3.1を参照してください。
The algorithm used to calculate the message digest MUST be the same as the "micalg" value used by the sender in the multipart/signed message. When no signature is received, the message-digest MUST be calculated using the algorithm specified by the "micalg" value in the Disposition-Notification-Options header. When no signature is received and no micalg parameter is provided, then the SHA-1 algorithm MUST be used to calculate the digest. This field is set only when the contents of the message are processed successfully. This field is used in conjunction with the recipient's signature on the MDN in order for the sender to verify non-repudiation of receipt.
メッセージダイジェストの計算に使用されるアルゴリズムは、MultiPart/署名されたメッセージで送信者が使用する「Micalg」値と同じでなければなりません。署名が受信されない場合、メッセージダイジェストは、処分 - 解決オプションヘッダーの「micalg」値で指定されたアルゴリズムを使用して計算する必要があります。署名が受信されず、Micalgパラメーターが提供されない場合、SHA-1アルゴリズムを使用してダイジェストを計算する必要があります。このフィールドは、メッセージの内容が正常に処理された場合にのみ設定されます。このフィールドは、送信者が領収書の非繰り返しを確認するために、MDNに関する受信者の署名と併せて使用されます。
AS3-MDN field names (e.g., "Disposition:", "Final-Recipient:") are case-insensitive (cf. RFC 3798, Section 3.1.1).
AS3-MDNフィールド名（例：「処分：」、「最終受信：」）はケース非感受性です（RFC 3798、セクション3.1.1を参照）。
AS3-MDN action-modes, sending-modes, AS3-disposition-types, and AS3- disposition-modifier values that are defined above, and user-supplied *( TEXT ) values are also case-insensitive. AS3 implementations MUST NOT make assumptions regarding the values supplied for AS3-MDN-warning-description or AS3-MDN-failure-description or for the values of any (optional) error, warning, or failure fields.
AS3-MDNアクション - モード、送信モード、AS3-ディスポジションタイプ、および上記で定義されているAS3-処分モジー値、およびユーザーがサプリした *（テキスト）値もケース非感受性です。AS3の実装は、AS3-MDN警告説明またはAS3-MDNフェールアードススクリプトに提供された値、または（オプションの）エラー、警告、または障害フィールドの値について、または虚偽の値について仮定してはなりません。
1. Unlike SMTP, for FTP transactions, Original-Recipient and Final Recipient SHOULD NOT be different. The value in Original-Message-ID MUST match the original Message-ID header value.
1. SMTPとは異なり、FTPトランザクションの場合、元のレシピエントと最終レシピエントは違いはありません。Original-Message-IDの値は、元のMessage-IDヘッダー値と一致する必要があります。
2. Refer to RFC 3462 and RFC 3798 for the formatting of the Content-Type entity-headers for the MDN.
2. MDNのコンテンツタイプのエンティティヘッダーのフォーマットについては、RFC 3462およびRFC 3798を参照してください。
3. Use an action-mode of "automatic-action" when the disposition described by the disposition type was a result of an automatic action, rather than an explicit instruction by the user for this message.
3. このメッセージのユーザーによる明示的な指示ではなく、処分タイプによって記述された処分が自動アクションの結果である場合、「自動アクション」のアクションモードを使用します。
4. Use an action-mode of "manual-action" when the disposition described by the disposition type was a result of an explicit instruction by the user rather than some sort of automatically performed action.
4. 「手動アクション」のアクションモードを使用して、処分タイプによって記述された処分が、何らかの自動的に実行されたアクションではなく、ユーザーによる明示的な指示の結果である場合。
5. Use a sending-mode of "MDN-sent-automatically" when the MDN is sent because the UA had previously been configured to do so.
5. UAが以前に設定されていたため、MDNが送信されたときに「MDN-Sent-Automatical」の送信モードを使用します。
6. Use a sending-mode of "MDN-sent-manually" when the user explicitly gave permission for this particular MDN to be sent.
6. ユーザーがこの特定のMDNを送信する許可を明示的に与えたときに、「MDN-Sent-sent-sent」の送信モードを使用します。
7. The sending-mode "MDN-sent-manually" is ONLY meaningful with "manual-action", not with "automatic-action".
7. 送信モード「MDN-Sent-hansal」は、「自動アクション」ではなく、「手動アクション」でのみ意味があります。
8. The "failed" disposition type MAY NOT be used for the situation in which there is some problem in processing the message other than interpreting the request for an MDN. The "processed" or other disposition type with appropriate disposition modifiers is to be used in such situations.
8. 「失敗した」処分タイプは、MDNの要求を解釈する以外にメッセージの処理に問題がある状況に使用されない場合があります。適切な気質修飾子を備えた「処理済み」またはその他の処分タイプは、そのような状況で使用されます。
9. An AS3 implementation MUST present to its trading partners an FTP-compliant server interface where inbound documents and MDNs are received.
9. AS3の実装は、インバウンドドキュメントとMDNが受信されるFTPに準拠したサーバーインターフェイスを取引パートナーに提示する必要があります。
10. An AS3 implementation MUST be able to retrieve inbound messages from its currently configured FTP server interface.
10. AS3の実装は、現在構成されているFTPサーバーインターフェイスからインバウンドメッセージを取得できる必要があります。
Note: Programming Notes 9 and 10 do not imply any specific method for supplying the FTP server interface. But, they do allow for several different types of implementations. Some vendors may choose to imbed an FTP-compliant server interface within their product, and others may choose to utilize off-the-shelf FTP servers to supply the required FTP server interface. Some may choose to utilize hosting services provided by their trading partner or by a third-party hosting service. Whichever method is utilized, an AS3 implementation MUST support rules 9 and 10.
注：プログラミングノート9および10は、FTPサーバーインターフェイスを提供するための特定の方法を意味するものではありません。しかし、それらはいくつかの異なるタイプの実装を可能にします。一部のベンダーは、製品内のFTPに準拠したサーバーインターフェイスを埋めることを選択する場合があり、他のベンダーは、既製のFTPサーバーを利用して、必要なFTPサーバーインターフェイスを提供することを選択できます。一部の人は、トレーディングパートナーまたはサードパーティのホスティングサービスが提供するホスティングサービスを利用することを選択する場合があります。どちらの方法を使用しても、AS3実装はルール9および10をサポートする必要があります。
11. AS3 implementations MAY imbed an FTP server interface within their product.
11. AS3の実装は、製品内のFTPサーバーインターフェイスを埋める可能性があります。
12. AS3 implementations MUST be configurable to allow the use of an external FTP hosting service.
12. AS3の実装は、外部FTPホスティングサービスの使用を許可するために構成可能でなければなりません。
Note: An external FTP hosting service may be hosted by a third-party or possibly hosted by your trading partner.
注：外部FTPホスティングサービスは、サードパーティがホストするか、トレーディングパートナーがホストする場合があります。
13. An AS3 implementation MUST be able to send business documents and MDNs to a trading partner's currently configured FTP server interface.
13. AS3の実装は、ビジネスドキュメントとMDNをトレーディングパートナーの現在構成されているFTPサーバーインターフェイスに送信できる必要があります。
14. An AS3 implementation may imbed FTP client code into their product or use a third-party FTP client.
14. AS3の実装は、FTPクライアントコードを製品に埋め込むか、サードパーティのFTPクライアントを使用する場合があります。
15. Example Configurations
15. 構成の例
1. Peer to Peer Trading Partner A (TPA) is using a local FTP server, and Trading Partner B (TPB) is using an imbedded FTP server.
1. ピアツーピアトレーディングパートナーA（TPA）はローカルFTPサーバーを使用しており、トレーディングパートナーB（TPB）は埋め込まれたFTPサーバーを使用しています。
[A Client] ----( connect )----> [B Server]
[A Client] ----( send )-------> [B Server] [AS3-Message]
[A Client] ----( disconnect )-> [B Server]
[A Server] <---( connect )----- [B Client]
[A Server] <---( send )-------- [B Client] [AS3-MDN]]
[A Server] <---( disconnect )-- [B Server]
[A Client] <---( GET )--------- [A Server]
2. Third-Party Hosting Both parties are using the same third-party-hosted FTP server.
2. サードパーティホスティングの両当事者は、同じサードパーティホストのFTPサーバーを使用しています。
[A Client] ----( connect )----> [Hosted Server]
[A Client] ----( send )-------> [Hosted Server] [AS3-Message]
[A Client] ----( disconnect )-> [Hosted Server]
[Hosted Server]( GET )--------> [B Client]
[Hosted Server] <---( connect )----- [B Client]
[Hosted Server] <---( send )-------- [B Client] [AS3-MDN]]
[Hosted Server] <---( disconnect )-- [B Client]
[A Client] <---( GET )--------- [Hosted Server]
3. Trading Partner Hosting TPA is using the imbedded FTP server hosted by TPB.
3. TPAをホストするトレーディングパートナーは、TPBによってホストされた埋め込まれたFTPサーバーを使用しています。
[A Client] ----( connect )----> [B Server]
[A Client] ----( send )-------> [B Server] [AS3-Message]
[A Client] ----( disconnect )-> [B Server]
[B Server] <---( connect )----- [B Client]
[B Server] <---( send )-------- [B Client] [AS3-MDN]]
[B Server] <---( disconnect )-- [B Client]
[A Client] <---( GET )--------- [B Server]
This section will provide a brief overview of how processed, error, failure, or warning notifications are used.
このセクションでは、処理、エラー、障害、または警告通知の使用方法の簡単な概要を説明します。
When a receipt or signed receipt is requested, and the received message contents are successfully processed by the receiving EDI UA, a receipt or MDN SHOULD be returned with the "disposition-type" set to "processed". When the MDN is sent automatically by the EDI UA, and there is no explicit way for a user to control the sending of the MDN, then the first part of the "disposition-mode" should be set to "automatic-action".
領収書または署名済みの領収書が要求され、受信したメッセージの内容が受信したEDI UAによって正常に処理される場合、「処理」に設定された「処理型」に領収書またはMDNを返す必要があります。MDNがEDI UAによって自動的に送信され、ユーザーがMDNの送信を制御する明示的な方法がない場合、「処分モード」の最初の部分は「自動アクション」に設定する必要があります。
When the MDN is being sent under user-configurable control, then the first part of the "disposition-mode" should be set to "manual-action". Since a request for a signed receipt should always be honored, the user MUST not be allowed to configure the UA not to send a signed receipt when the sender requests one.
MDNがユーザー構成可能なコントロールの下で送信されている場合、「処分モード」の最初の部分は「手動アクション」に設定する必要があります。署名済みの領収書のリクエストは常に尊重される必要があるため、ユーザーは、送信者が要求したときに署名済みの領収書を送信しないようにUAを構成することを許可されてはなりません。
The second part of the "disposition-mode" is set to "MDN-sent-manually" if the user gave explicit permission for the MDN to be sent. Again, the user MUST not be allowed to explicitly refuse to send a signed receipt when the sender requests one. The second part of the "disposition-mode" is set to "MDN-sent-automatically" whenever the EDI UA sends the MDN automatically, regardless of whether the sending was under a user's, an administrator's, or software control.
「処分モード」の2番目の部分は、ユーザーがMDNを送信するために明示的な許可を与えた場合、「MDN-Sent-sent-sent」に設定されます。繰り返しますが、送信者が要求したときに、ユーザーが署名された領収書の送信を明示的に拒否することを許可されてはなりません。「処分モード」の2番目の部分は、EDI UAがユーザー、管理者、またはソフトウェアコントロールの下にあるかどうかにかかわらず、EDI UAがMDNを自動的に送信するたびに「MDN-Sent-Automatical」に設定されます。
Since EDI content is generally handled automatically by the EDI UA, a request for a receipt or signed receipt will generally return the following in the "disposition-field":
EDIコンテンツは通常、EDI UAによって自動的に処理されるため、領収書または署名された領収書のリクエストは、通常、「処分場」で以下を返します。
Disposition: automatic-action/MDN-sent-automatically; processed
処分：自動アクション/MDN-Sent-Automatical;処理
Note this specification does not restrict the use of the "disposition-mode" to just automatic actions. Manual actions are valid as long as it is kept in mind that a request for a signed receipt MUST be honored.
この仕様は、自動アクションのみに「処分モード」を使用することを制限していません。手動アクションは、署名された領収書のリクエストを尊重する必要があることを念頭に置いている限り有効です。
The request for a signed receipt requires the use of two "disposition-notification-options", which specify the protocol format of the returned signed receipt, and the MIC algorithm used to calculate the MIC over the message contents. The "disposition-field" values that should be used in the case where the message content is being rejected or ignored should be specified in the MDN "disposition-field" as below. (An example of this case is when the EDI UA determines that a signed receipt cannot be returned because it does not support the requested protocol format, so the EDI UA chooses not to process the message contents itself.)
署名された領収書のリクエストには、返された署名された領収書のプロトコル形式を指定する2つの「気質 - 解釈オプション」の使用と、メッセージコンテンツ上のマイクを計算するために使用されるマイクアルゴリズムが必要です。メッセージコンテンツが拒否または無視されている場合に使用する必要がある「処分場」値は、以下のようにMDNの「処分場」で指定する必要があります。（このケースの例は、EDI UAが要求されたプロトコル形式をサポートしていないために署名された領収書を返すことができないと判断した場合、EDI UAはメッセージコンテンツ自体を処理しないことを選択します。）
Disposition: "disposition-mode"; failed/Failure: unsupported Format
The "failed" AS3-disposition-type should be used when a failure occurs that prevents the proper generation of an MDN.
MDNの適切な生成を防ぐ障害が発生した場合、「失敗した」AS3-浸透型を使用する必要があります。
For example, this disposition-type would apply if the sender of the message requested the application of an unsupported message-integrity-check (MIC) algorithm.
たとえば、メッセージの送信者がサポートされていないメッセージ-Integrity-Check（MIC）アルゴリズムの適用を要求した場合、この処分型は適用されます。
The "failure:" AS3-disposition-modifier-extension should be used with an implementation-defined description of the failure.
「障害：」AS3-disposition-Modifier-Extensionは、障害の実装定義の説明で使用する必要があります。
Further information about the failure may be contained in a failure-field. The syntax of the "failed" "disposition-type" is general, allowing the sending of any textual information along with the "failed" "disposition-type". Implementations WILL support any printable textual characters after the Failure disposition-type.
障害に関する詳細情報は、障害フィールドに含まれる場合があります。「失敗した」「処分型」の構文は一般的であり、「失敗した」「処分型」とともにテキスト情報を送信できます。実装は、故障処分型の後の印刷可能なテキスト文字をサポートします。
For use in Internet EDI, the following "failed" values are pre-defined and MUST be supported:
インターネットEDIで使用するには、次の「失敗した」値が事前に定義されており、サポートする必要があります。
"Failure: unsupported format" "Failure: unsupported MIC-algorithms"
「障害：サポートされていない形式」「失敗：サポートされていないマイクアルゴリズム」
When errors occur in processing the received message, other than content, the "disposition-field" should be set to the "processed" "disposition-type" value and the "error" "disposition-modifier" value.
コンテンツ以外の受信メッセージの処理でエラーが発生した場合、「処理型」の「処理された」「処理型」値と「エラー」「処分モジー」値に設定する必要があります。
The "error" AS3-disposition-modifier with the "processed" disposition-type should be used to indicate that an error of some sort occurred that prevented successful processing of the message.
「処理された」処分型を備えた「エラー」AS3-ディスポジションモジファイアを使用して、メッセージの処理の成功を妨げる何らかのエラーが発生したことを示す必要があります。
Further information may be contained in an error-field.
詳細については、エラーフィールドに含まれる場合があります。
An "error:" AS3-disposition-modifier-extension should be used to combine the indication of an error with a pre-defined description of a specific, well-known error. Further information about the error may be contained in an error-field.
「エラー：」AS3-disposition-Modifier-Extensionを使用して、エラーの表示と特定のよく知られたエラーの事前定義された説明と組み合わせる必要があります。エラーの詳細情報は、エラーフィールドに含まれる場合があります。
For use in Internet EDI, the following "error" "disposition-modifier" values are defined:
インターネットEDIで使用するために、次の「エラー」「処分モジー」値が定義されています。
"Error: decryption-failed" The receiver could not decrypt the message contents.
「エラー：復号化された」レシーバーは、メッセージの内容を解読できませんでした。
"Error: authentication-failed" The receiver could not authenticate the sender.
「エラー：認証装置」レシーバーは送信者を認証できませんでした。
"Error: integrity-check-failed" The receiver could not verify content integrity.
「エラー：Integrity-Check-Failed」レシーバーはコンテンツの整合性を確認できませんでした。
"Error: insufficient-message-security" The security level of the message did not match the agreed level between TPs.
「エラー：問題の不十分なセキュリティ」メッセージのセキュリティレベルは、TP間の合意されたレベルと一致しませんでした。
"Error: decompression-failed" The receiver could not decompress the message contents.
「エラー：減圧症」レシーバーはメッセージの内容を減圧できませんでした。
"Error: unexpected-processing-error" A catch-all for any additional processing errors.
「エラー：予期しない処理エラー」追加の処理エラーのキャッチオール。
An example of how the "disposition-field" would look when processing errors, other than content, are detected is as follows:
コンテンツ以外の処理エラーが検出されるときに「処分場」がどのように見えるかの例は次のとおりです。
EXAMPLE Disposition: "disposition-mode"; processed/Error: decryption-failed
処分の例：「処分モード」;処理/エラー：復号化された
Situations arise in EDI where even if a trading partner cannot be authenticated correctly, the trading partners still agree to continue processing the EDI transactions. Transaction reconciliation is done between the trading partners at a later time. In the content processing warning situations described above, the "disposition-field" SHOULD be set to the "processed" "disposition-type" value, and the "warning" "disposition-modifier" value.
EDIでは状況が発生し、取引パートナーを正しく認証できなくても、取引パートナーは依然としてEDIトランザクションの処理を継続することに同意します。取引調整は、後で取引パートナー間で行われます。上記のコンテンツ処理の警告状況では、「処理型」を「処理された」「処理型」値に設定する必要があり、「警告」「処分モジー」値が値に設定する必要があります。
The "warning" AS3-disposition-modifier should be used with the "processed" disposition-type to indicate that the message was successfully processed but that an exceptional condition occurred.
「警告」AS3-ディスポジションモジーファイアは、「処理された」処分型で使用して、メッセージが正常に処理されたが、例外的な条件が発生したことを示す必要があります。
Further information may be contained in a warning-field.
詳細については、警告場に含まれる場合があります。
A "warning:" AS3-disposition-modifier-extension should be used to combine the indication of a warning with an implementation-defined description of the warning. Further information about the warning may be contained in a warning-field.
「警告：」AS3-Disposition-Modifier-Extensionを使用して、警告の表示と警告の実装定義の説明を組み合わせる必要があります。警告の詳細は、警告場に含まれる場合があります。
For use in Internet EDI, the following "warning" "disposition-modifier" values are defined:
インターネットEDIで使用するために、次の「警告」「処分モジー」値が定義されています。
"Warning: authentication-failed, processing continued"
「警告：認証が請求され、処理が継続されます」
An example of how the "disposition-field" would look when processing warnings, other than content, are detected is as follows:
コンテンツ以外の警告を処理するときに「処分場」がどのように見えるかの例は、次のとおりです。
EXAMPLE Disposition: "disposition-mode"; processed/Warning: authentication-failed, processing continued
処分の例：「処分モード」;処理/警告：認証が除外され、処理が続きました
In the near term, the exchange of public keys and certification of these keys must be handled as part of the process of establishing a trading partnership. The UA and/or EDI application interface must maintain a database of public keys used for encryption or signatures, in addition to the mapping between EDI trading partner ID and FTP URL/URI. The procedures for establishing a trading partnership and configuring the secure EDI messaging system might vary among trading partners and software packages.
短期的には、公開鍵の交換とこれらのキーの認証は、取引パートナーシップを確立するプロセスの一環として処理する必要があります。UAおよび/またはEDIアプリケーションインターフェイスは、EDIトレーディングパートナーIDとFTP URL/URIの間のマッピングに加えて、暗号化または署名に使用されるパブリックキーのデータベースを維持する必要があります。取引パートナーシップを確立し、安全なEDIメッセージングシステムを構成する手順は、取引パートナーとソフトウェアパッケージによって異なる場合があります。
X.509 certificates are REQUIRED. It is RECOMMENDED that trading partners self-certify each other if an agreed-upon certification authority is not used. This applicability statement does NOT require the use of a certification authority.
X.509証明書が必要です。合意された認証機関が使用されない場合、貿易パートナーはお互いを自己認証することをお勧めします。この適用性声明は、認証機関の使用を必要としません。
The use of a certification authority is therefore OPTIONAL. Certificates may be self-signed. It is RECOMMENDED that when trading partners are using S/MIME, that they also exchange public key certificates using the recommendations specified in the S/MIME Version 3.1 Message Specification.
したがって、認証機関の使用はオプションです。証明書は自己署名されている場合があります。取引パートナーがS/MIMEを使用している場合、S/MIMEバージョン3.1メッセージ仕様で指定された推奨事項を使用して公開キー証明書も交換することをお勧めします。
The message formats and S/MIME conformance requirements for certificate exchange are specified in this document. In the long term, additional Internet-EDI standards may be developed to simplify the process of establishing a trading partnership, including the third-party authentication of trading partners, as well as attributes of the trading relationship.
このドキュメントでは、メッセージフォーマットとS/MIMEの適合要件がこのドキュメントで指定されています。長期的には、取引パートナーの第三者認証や取引関係の属性など、取引パートナーシップを確立するプロセスを簡素化するために、追加のインターネットEDI標準が開発される場合があります。
This entire document is concerned with secure transport of business-to-business data, and it considers both privacy and authentication issues.
このドキュメント全体は、企業間データの安全な輸送に関係しており、プライバシーと認証の両方の問題を考慮しています。
Extracted from S/MIME Version 2 Message Specification [21]:
S/MIMEバージョン2のメッセージ仕様から抽出[21]：
40-bit encryption is considered weak by most cryptographers. Using weak cryptography in S/MIME offers little actual security over sending plaintext. However, other features of S/MIME, such as the specification of tripleDES and the ability to announce stronger cryptographic capabilities to parties with whom you communicate, allow senders to create messages that use strong encryption. Using weak cryptography is never recommended unless the only alternative is no cryptography. When feasible, sending and receiving agents should inform senders and recipients the relative cryptographic strength of messages.
40ビット暗号化は、ほとんどの暗号化者によって弱いと見なされます。S/MIMEで弱い暗号化を使用すると、プレーンテキストの送信に関する実際のセキュリティはほとんどありません。ただし、3倍の仕様や、コミュニケーションをとる当事者により強力な暗号化能力を発表する能力など、S/MIMEの他の機能により、送信者は強力な暗号化を使用するメッセージを作成できます。唯一の代替手段が暗号化されていない場合を除き、弱い暗号化を使用することは決して推奨されません。実行可能な場合、送信および受信エージェントは、送信者と受信者にメッセージの相対的な暗号的な強さを通知する必要があります。
Extracted from S/MIME Version 3.1 Certificate Handling [11]:
S/MIMEバージョン3.1証明書処理[11]から抽出：
When processing certificates, there are many situations where the processing might fail. Because the processing may be done by a user agent, a security gateway, or other program, there is no single way to handle such failures. Just because the methods to handle the failures has not been listed, however, the reader should not assume that they are not important. The opposite is true: if a certificate is not provably valid and associated with the message, the processing software should take immediate and noticeable steps to inform the end user about it.
証明書を処理する場合、処理が失敗する可能性のある多くの状況があります。処理はユーザーエージェント、セキュリティゲートウェイ、またはその他のプログラムによって行われる可能性があるため、そのような障害を処理する方法はありません。ただし、障害を処理する方法がリストされていないからといって、読者はそれらが重要ではないと想定すべきではありません。逆の場合は、証明書が有効でなくメッセージに関連付けられていない場合、処理ソフトウェアは、エンドユーザーにそれを通知するために即座に顕著な手順を実行する必要があります。
Some of the many places where signature and certificate checking might fail include:
署名と証明書のチェックが失敗する可能性のある多くの場所のいくつかは次のとおりです。
- no Internet mail addresses in a certificate matches the sender of a message, if the certificate contains at least one mail address - no certificate chain leads to a trusted CA - no ability to check the Certificate Revocation List (CRL) for a certificate - an invalid CRL was received - the CRL being checked is expired - the certificate is expired - the certificate has been revoked 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.
- 証明書のインターネットメールアドレスはメッセージの送信者と一致しません。証明書に少なくとも1つのメールアドレスが含まれている場合 - 証明書チェーンが信頼できるCAにつながる場合 - 証明書の取り消しリスト（CRL）を確認する能力はありません - 無効なCRLが受信されました - チェックされているCRLの有効期限が切れます - 証明書の有効期限が切れます - 証明書は取り消されました。小切手が失敗した場合はどうするかを決定します。
The following certificate types MUST be supported. With URL Without URL Self Certified Certification Authority Certified
次の証明書の種類をサポートする必要があります。URLなしのURLを使用して、自己認証認定局の認定を受けています
The complete certification chain MUST be included in all certificates. All certificate verifications MUST "chain to root". Additionally, the certificate hash should match the hash recomputed by the receiver.
完全な認定チェーンは、すべての証明書に含める必要があります。すべての証明書の検証は、「ルートするためにチェーン」する必要があります。さらに、証明書のハッシュは、受信機によって再計算されたハッシュと一致する必要があります。
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[1] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート5：適合基準と例」、RFC 2049、1996年11月。
[2] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, March 1995.
[2] Crocker、D。、「EDIオブジェクトのMIMEカプセル化」、RFC 1767、1995年3月。
[3] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[3] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、1985年10月。
[4] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 2228, October 1997.
[4] Horowitz、M。およびS. Lunt、「FTP Security Extensions」、RFC 2228、1997年10月。
[5] Harding, T., Drummond, R., and C. Shih, "MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet", RFC 3335, September 2002.
[5] Harding、T.、Drummond、R。、およびC. Shih、「Mimeベースのセキュアピアツーピアビジネスデータインターネット上の交換」、RFC 3335、2002年9月。
[6] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[6] Hansen、T。およびG. Vaudreuil、「メッセージ処分通知」、RFC 3798、2004年5月。
[7] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[7] Galvin、J.、Murphy、S.、Crocker、S.、およびN. Freed、「Mimeのセキュリティマルチパート：MultiPart/Signed and MultiPart/暗号化」、RFC 1847、1995年10月。
[8] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[8] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[9] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[10] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[10] Ramsdell、B。、「Secure/Multipurpose Internet Mail拡張機能（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[11] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[11] Ramsdell、B。、「セキュア/多目的インターネットメール拡張機能（S/MIME）バージョン3.1証明書処理」、RFC 3850、2004年7月。
[12] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[12] Vaudreuil、G。、「メールシステム管理メッセージのレポートのマルチパート/レポートコンテンツタイプ」、RFC 3462、2003年1月。
[13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[13] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[14] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", STD 11, RFC 822, August 1982.
[14] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。
[15] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[15] Resnick、P。、「インターネットメッセージフォーマット」、RFC 2822、2001年4月。
[16] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[16] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[17] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[17] Gutmann、P。、「暗号化メッセージ構文（CMS）の圧縮データコンテンツタイプ」、RFC 3274、2002年6月。
[18] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, October 2005.
[18] Ford-Hutchinson、P。、「TLSでFTPの保護」、RFC 4217、2005年10月。
[19] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[19] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[20] Harding, T., "Compressed Data for EDIINT", Work in Progress, January 2007.
[20] Harding、T。、「EDIINTの圧縮データ」、2007年1月、進行中の作業。
[21] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.
[21] Dusse、S.、Hoffman、P.、Ramsdell、B.、Lundblade、L。、およびL. Repka、「S/Mimeバージョン2メッセージ仕様」、RFC 2311、1998年3月。
[22] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[22] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[23] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[23] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
NOTE: All examples are provided as an illustration only, and are not considered part of the protocol specification. If an example conflicts with the protocol definitions specified above or with that of a referenced RFC, the example is wrong.
注：すべての例はイラストとしてのみ提供されており、プロトコル仕様の一部とは見なされません。例が上記または参照されたRFCのプロトコル定義と競合する場合、例は間違っています。
Date: Wed, 31 Jul 2002 13:34:50 GMT
AS3-Version: 1.0
AS3-From: cyclone
AS3-To: "trading partner"
Message-Id: <200207310834482A70BF63@host.com>
Disposition-Notification-To: ftp://host:port/mdnbox
Disposition-Notification-Options: signed-receipt-
protocol=optional,pkcs7-signature;
signed-receipt-micalg=optional,sha1
Content-Type: multipart/signed; boundary="as3BouNdary1as3";
protocol="application/pkcs7-signature"; micalg=sha1
Content-Length: 3075
--as3BouNdary1as3
Content-Type: application/edi-x12
Content-Disposition: Attachment; filename=rfc1767.dat
[ISA ...EDI transaction data...IEA...]
[ISA ... EDIトランザクションデータ... IEA ...]
--as3BouNdary1as3 Content-Type: application/pkcs7-signature
-as3boundary1as3コンテンツタイプ：Application/PKCS7-Signature
[omitted binary pkcs7 signature data] --as3BouNdary1as3--
[省略バイナリPKCS7署名データ] -AS3Boundary1as3---
Date: Wed, 31 Jul 2002 13:34:50 GMT
AS3-From: "trading partner"
AS3-To: cyclone
AS3-Version: 1.0
Message-ID: <709700825.1028122454671.JavaMail@ediXchange>
Content-Type: multipart/signed; micalg=sha1;
protocol="application/pkcs7-signature";
boundary="----=_Part_57_648441049.1028122454671"
Content-Length: 1024
------=_Part_57_648441049.1028122454671
& Content-Type: multipart/report;
& Report-Type=disposition-notification;
& boundary="----=_Part_56_1672293592.1028122454656"
&
&------=_Part_56_1672293592.1028122454656
&Content-Type: text/plain
&Content-Transfer-Encoding: 7bit
&
&MDN for -
& Message ID: <200207310834482A70BF63@host.com>
& From: cyclone
& To: "trading partner"
& Received on: 2002-07-31 at 09:34:14 (EDT)
& Status: processed
& Comment: This is not a guarantee that the message has been
& completely processed or understood by the receiving translator
&
&------=_Part_56_1672293592.1028122454656
& Content-Type: message/disposition-notification
& Content-Transfer-Encoding: 7bit
&
& Reporting-UA: AS3 Server
& Original-Recipient: rfc822; "trading partner"
& Final-Recipient: rfc822; "trading partner"
& Original-Message-ID: <200207310834482A70BF63@host.com>
& Received-content-MIC: 7v7F++fQaNB1sVLFtMRp+dF+eG4=, sha1
& Disposition: automatic-action/MDN-sent-automatically; processed
&
&------=_Part_56_1672293592.1028122454656--
------=_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 RFC 3851 [10], "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification".
2. MultiPart/signedをProtocol = "Application/PKCS7-Signature"で準備する方法の詳細については、RFC 3851 [10]、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様」を参照してください。
3. Note that the textual first body part of the multipart/report can be used to include a more detailed explanation of the error conditions reported by the disposition headers. The first body part of the multipart/report, when used in this way, allows a person to better diagnose a problem in detail.
3. マルチパート/レポートのテキストの最初のボディ部分を使用して、気質ヘッダーによって報告されたエラー条件のより詳細な説明を含めることができることに注意してください。マルチパート/レポートの最初のボディ部分は、この方法で使用されると、人が問題を詳細に診断することができます。
4. As specified by RFC 3462 [12], returning the original or portions of the original message in the third body part of the multipart/report is not required. This is an optional body part. However, it is RECOMMENDED that this body part be omitted or left blank.
4. RFC 3462 [12]で指定されているように、MultiPart/レポートの3番目のボディ部分で元のメッセージのオリジナルまたは部分を返す必要はありません。これはオプションのボディの部分です。ただし、この体の部分を省略または空白のままにすることをお勧めします。
Authors' Addresses
著者のアドレス
Terry Harding Axway 8388 E. Hartford Drive, Suite 100 Scottsdale, AZ 85255 USA
Terry Harding Axway 8388 E. Hartford Drive、Suite 100 Scottsdale、AZ 85255 USA
EMail: tharding@us.axway.com
Richard Scott Axway 8388 E. Hartford Drive, Suite 100 Scottsdale, AZ 85255 USA
リチャード・スコット・アクウェイ8388 E.ハートフォード・ドライブ、スイート100スコッツデール、アリゾナ州85255 USA
EMail: rscott@us.axway.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。