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
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message.
この適用性に関する声明（AS）はしっかりとXMLのためのファイル転送プロトコル（FTP）を使用して、構造化された業務データを交換する方法について説明し、バイナリ、電子データ交換（EDI - ANSI X12やUN / EDIFACT）、またはビジネスツーのために使用される他のデータ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の前の仕事は、[5] [2] EDIデータのMIMEコンテンツタイプを指定することに注力し、SMTPを介してセキュアなEC / EDIトランスポートをサポートするために、この作業を拡張します。このドキュメントでは、データセキュリティ機能、具体的には、データのプライバシー、データの整合性、信頼性、起源の否認防止、およびFTPを超える領収書の否認防止の包括的なセットを指定するには、RFC 1767を拡張したものです。また、このドキュメントでは、現代的な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
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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サーバーをポーリング開梱し、メッセージデータを処理し、符号付きまたは符号なしているマルチパート/レポート内のメッセージ気質の確認が含まれている発信元に対する応答を生成します。この要求は、/トランザクション交換が信頼性の高い、安全な提供、およびEDIまたはFTPを使用して、他のビジネスデータのトランスポートを認証済み返信。セキュリティプロトコルとも使用される構造は、これらの送信の監査レコードをサポート。
The purpose of these specifications is to ensure interoperability between B2B Electronic Commerce user agents, invoking some or all of the commonly expected security features. This document is also NOT limited to strict EDI use, but applies to any electronic commerce application where business data needs to be exchanged over the Internet in a secure manner.
これらの仕様の目的は、一般的に期待されるセキュリティ機能の一部またはすべてを呼び出す、B2B電子商取引のユーザーエージェント間の相互運用性を確保することです。この文書はまた、厳格なEDIの使用に限定されるものではなく、業務データを安全な方法で、インターネット上で交換する必要のある任意の電子商取引アプリケーションに適用されます。
AS3 Applicability Statement 3. This is the third applicability statement produced by the IETF EDIINT working group.
AS3の適用に関する声明3.これは、IETF EDIINTワーキンググループによって生成第三の適用文です。
EDI Electronic Data Interchange
ただし、電子データ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.
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.
インターネットMIMEメッセージに暗号署名および/または暗号化サービスを追加するためのS / MIME Aフォーマットとプロトコル。
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.
SHA-1 A secure, one-way hash algorithm used in conjunction with digital signature. SHA-1 is the recommend algorithm for AS3.
SHA-1のデジタル署名と併せて使用セキュアな一方向ハッシュアルゴリズム。 SHA-1は、AS3のためのアルゴリズムをお勧めします。
MD5 A secure, one-way hash algorithm used in conjunction with digital signature. This algorithm is acceptable but not recommended due to its short key length and known weaknesses.
MD5デジタル署名と併せて使用セキュアな一方向ハッシュアルゴリズム。このアルゴリズムは許容されますが、その短い鍵長と既知の弱点にはお勧めしません。
MIC The message integrity check (MIC) is a representation of the message digest, which results from the application of the selected hash algorithm to the content to be signed. Of particular interest is the digital signature, which includes an encrypted copy of the digest. Additionally, an MDN containing a Received-content-MIC header will also contain (as that header's value) a base-64-encoded representation of the digest.
MICメッセージ完全性チェック（MIC）は、署名されるべきコンテンツを選択したハッシュアルゴリズムのアプリケーションに起因するメッセージダイジェストの表示です。特に興味深いのダイジェストの暗号化されたコピーを含むデジタル署名です。また、受信コンテンツMICヘッダを含むMDNはまた（そのヘッダの値として）ダイジェストのベース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.
- 組織は、EDI / ECデータ記号を送信し、S / MIMEを使用してデータを暗号化します。加えて、メッセージは、メッセージの送信者に返される署名された領収書を要求します。
- The receiving organization decrypts the message and verifies the signature, resulting in verified integrity of the data and authenticity of the sender.
- 受信した組織は、メッセージを復号化し、データと送信者の真正性の検証完全性をもたらす、署名を検証します。
- The receiving organization then returns a signed receipt, as requested to the sending organization in the form of a message disposition notification. This signed receipt will contain the hash of the signature from the received message, indicating to the sender that the received message was verified and/or decrypted properly.
- メッセージ気質通知の形で送信組織に要求されるように、受信組織は、その後、署名された領収書を返します。この署名された領収書は、受信したメッセージを検証及び/又は適切に復号化されたことを送信者に知らせる、受信したメッセージからの署名のハッシュを含むことになります。
The above describes functionality that, if implemented, will satisfy all security requirements and provide non-repudiation of receipt for the exchange. While trading partners will usually want to utilize the STL, this specification does not require it.
上記は、実装されている場合、すべてのセキュリティ要件を満たし、交換のための領収書の否認防止を提供します機能について説明します。取引先は通常、STLを利用したいと思うでしょうが、この仕様は、それを必要としません。
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パッケージには表示されません。インターネットに（付加価値通信網またはのVANと呼ばれる）は、既存の商用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はEDIFACTのセキュリティを提供します。この仕様は、これらのセキュリティ標準の使用または不使用を規定していません。これらは、本明細書で、両方しかしおそらく冗長、完全に互換性があります。
- Encrypted or un-encrypted data
- 暗号化または非暗号化されたデータ
This specification allows for EDI/EC message exchange where the EDI/EC data can be either un-protected or protected by means of encryption.
この仕様は、EDI / ECデータが非保護または暗号化によって保護することができるいずれかのEDI / ECのメッセージ交換を可能にします。
- Signed or unsigned data
- 符号付きまたは符号なしデータ
This specification allows for EDI/EC message exchange with or without digital signature of the original EDI transmission.
この仕様は伴うまたは元のEDI送信のデジタル署名なしのEDI / ECのメッセージ交換を可能にします。
- Use of receipt or not
- 使用領収書のか
This specification allows for EDI/EC message transmission with or without a request for receipt notification. If a signed receipt notification is requested, however, a MIC value is REQUIRED as part of the returned receipt, unless an error condition occurs that results in the inability to compute a valid digest. (Such a case would result, for instance, if an encrypted message could not be decrypted.) Under such circumstances, an unsigned receipt (MDN) SHOULD be returned with the correct "disposition modifier" error value.
この仕様は、または受領通知の要求なしEDI / ECのメッセージ送信を可能にします。署名された受領通知が要求された場合、エラー状態ができないことの結果は、有効なダイジェストを計算することが発生しない限り、しかし、MIC値は、返される受信の一部として必要とされます。 （暗号化されたメッセージを解読することができなかった場合、このような場合には、例えば、生じる。）このような状況下では、符号なしのレシート（MDN）が正しい「気質修飾語」エラー値が返されるべきです。
- 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.
この仕様は、RFCで記載されたガイドラインに依存して3852 [9]と3851 [10]。これらのRFCの第一は、暗号メッセージ構文（CMS）を記述し、第二は、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個のセキュリティ順列は、任意の取引関係が可能です。
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.送信者は、暗号化されていないデータを送信し署名した領収書を要求します。受信機は、署名された領収書を返送します。
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.送信者は、暗号化されたデータを送信し署名した領収書を要求します。受信機は、署名された領収書を返送します。
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にし、ハーディングの文書、「EDIINTのための圧縮データ」で見ることができるRFC 3274実装の詳細のアプリケーションを介して送信されるデータの圧縮をサポートしています。
RFC 959 specifies how data is transferred using the File Transfer Protocol (FTP)
RFC 959は、データをファイル転送プロトコル（FTP）を使用して転送される方法を指定します
This RFC describes a framework for providing security services to FTP.
このRFCは、FTPへのセキュリティサービスを提供するためのフレームワークについて説明します。
This document defines security multiparts for MIME: multipart/encrypted and multipart/signed.
このドキュメントは、MIMEのためのセキュリティマルチパートを定義しています/マルチ/暗号化およびマルチパートが署名しました。
RFC 3462 defines the use of the multipart/report content type, upon which RFC 3798 builds to define the Message Disposition Notification.
RFC 3462は、RFC 3798はメッセージ気質通知を定義するために構築し、その上にマルチパート/レポート・コンテンツ・タイプの使用を定義します。
This RFC defines the use of content type "application" for ANSI X12 (application/EDI-X12), EDIFACT (application/EDIFACT), and mutually defined EDI (application/EDI-Consent).
このRFCは、ANSI X12（アプリケーション/ EDI-X12）、EDIFACT（アプリケーション/ EDIFACT）、および相互定義EDI（アプリケーション/ EDI-同意）のコンテンツタイプ "アプリケーション" の使用を定義します。
These are the basic MIME standards, upon which all MIME-related RFCs build, including this one. Key contributions include definitions of "content type", "sub-type", and "multipart", as well as encoding guidelines, which establish 7-bit US-ASCII as the canonical character set to be used in Internet messaging.
これらはすべて、MIME関連のRFCはこの1つを含む、構築、その上に基本的なMIME規格です。主な貢献は、インターネットメッセージングで使用されるように設定正規の文字として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は、両方の符号付きおよび符号なしの領収書を提供するために、本明細書で使用される車両です。
3.8. : CMS [] and : S/MIME Version 3.1 Message Specification []
3.8. ：CMS []と：S / MIMEバージョン3.1メッセージ仕様[]
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の文脈における証明書の取り扱いについて説明しています。
3.10. : Compressed Data Content Type for Cryptographic Message Syntax (CMS) []
3.10. ：暗号メッセージ構文（CMS）のための圧縮されたデータcontent type []
This specification provides a mechanism to wrap compressed data within a CMS object.
この仕様はCMSオブジェクト内の圧縮されたデータをラップするためのメカニズムを提供します。
This RFC defines the use of content type "application" for XML. Note that while conforming implementations SHOULD support the expanded syntax that RFC 3023 introduces for the "+xml" suffix, no support for external parsed entity types is anticipated (as it adds significant complexity to signature processing).
このRFCは、XMLのコンテンツタイプ「アプリケーション」の使用を定義します。適合実装はRFC 3023が「+ XML」サフィックスの導入拡張構文をサポートするべきである（それは署名処理に重大な複雑さを付加するように）、外部解析対象エンティティタイプはサポートが予想されていないことに留意されたいです。
The basic structure of AS3 messages comprises MIME encapsulated data with both customary MIME headers and a few additional AS3-specific outer headers. The structures below are described hierarchically in terms of which RFCs have been applied to form the specific structure. The reader is referred directly to the referenced RFCs for implementation details.
AS3メッセージの基本的な構造は、MIMEは、慣用MIMEヘッダといくつかの追加AS3固有アウターヘッダの両方でデータをカプセル化備えます。以下の構造は、RFCは特定の構造を形成するために適用されているという点で階層的に記載されています。読者は実装の詳細のために参照するRFCに直接呼ばれます。
Any additional restrictions imposed by this AS are specifically discussed in the sections that follow.
このASによって課される追加の制限は特に次のセクションで説明されています。
No encryption, no signature
暗号化なし、無署名
-RFC822/2045 -RFC1767/RFC2376 (application/EDIxxxx or /xml)
/ 2045 -RFC822 -RFC1767 / RFC2376（アプリケーション/ EDIxxxx又は/ XML）
No encryption, signature
暗号化なし、署名
-RFC822/2045 -RFC1847 (multipart/signed) -RFC1767/RFC2376 (application/EDIxxxx or /xml) -RFC3851 (application/pkcs7-signature)
-RFC822 / 2045 -RFC1847（マルチパート/署名された）-RFC1767 / RFC2376（アプリケーション/ EDIxxxx又は/ XML）-RFC3851（アプリケーション/ PKCS7署名）
Encryption, no signature
暗号化、署名なし
-RFC822/2045 -RFC3851 (application/pkcs7-mime) -RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
/ 2045 -RFC822 -RFC3851（アプリケーション/ PKCS7-MIME）-RFC1767 / RFC2376（アプリケーション/ EDIxxxx又は/ XML）（暗号化）
Encryption, signature
暗号化、署名
-RFC822/2045 -RFC3851 (application/pkcs7-mime) -RFC1847 (multipart/signed)(encrypted) -RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted) -RFC3851 (application/pkcs7-signature)(encrypted)
-RFC822 / 2045 -RFC3851（アプリケーション/ PKCS7-MIME）-RFC1847（マルチパート/署名された）（暗号化）-RFC1767 / RFC2376（アプリケーション/ EDIxxxx又は/ XML）（暗号化）-RFC3851（アプリケーション/ PKCS7署名）（暗号化）
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（マルチパート/署名された）-RFC3798（メッセージ/気質通知）-RFC3851（アプリケーション/ PKCS7署名）
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
コンテンツタイプ：マルチパート/コンテンツタイプを締結：マルチパート/レポート・コンテンツ・タイプ：メッセージ/気質通知コンテンツタイプ：アプリケーション/ PKCS7署名のコンテンツタイプ：アプリケーション/ PKCS7-MIMEコンテンツタイプ：アプリケーション/ EDI-X12コンテンツタイプ：アプリケーション/ EDIFACTのContent-Type：アプリケーション/ EDI-同意のContent-Type：アプリケーション/ XML
The AS3-From and AS3-To headers have been provided to assist the sender and the recipient of an EC document to identify each other:
AS3-FromとAS3-TOヘッダは、互いを識別するために、送信者とECの文書の受信者を支援するために提供されています。
AS3-From: < AS3-name > AS3-To: < AS3-name >
AS3-から：<AS3-名> AS3-TO：<AS3名>
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テキスト= "！" /;印刷可能なASCII文字％d35-91 /。二重引用符（％D34）％のd93-126除きます。またはバックスラッシュ（％のD92）
AS3-qtext = AS3-text / SP ; allow space only in quoted text
AS3-qtext = AS3-テキスト/ SP;だけ引用されたテキストにスペースを許可します
AS3-quoted-pair = "\" DQUOTE / ; \" or "\" "\" ; \\
AS3引用符で囲まれたペア=「\」DQUOTE /。 \" または "\" "\" ; \\
AS3-quoted-name = DQUOTE 1*128( AS3-qtext / AS3-quoted-pair) DQUOTE
AS3引用名= DQUOTE 1×128（AS3-qtext / AS3引用対）DQUOTE
AS3-atomic-name = 1*128AS3-text
AS3-アトミック名= 1 * 128AS3テキスト
AS3-name = AS3-atomic-name / AS3-quoted-name
AS3名= AS3-原子名/ AS3引用符で囲まれた名
Note: SP and DQUOTE are defined in [ABNF]RFC 4234.
注：SPとDQUOTEは、RFC 4234 [ABNF]で定義されています。
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-からヘッダ値とAS3-TOヘッダー値はそれぞれ1〜128の印刷可能なASCII文字を含むAS3-名でなければなりません。ヘッダは、折り畳まれてはならず、これらのヘッダのそれぞれの値は、大文字と小文字が区別されます。
The AS3-quoted-name SHOULD be used only if the AS3-name does not conform to AS3-atomic-name.
AS3引用符で囲まれた名は、AS3-nameはAS3-アトミック名に準拠していない場合にのみ使用されるべきです。
The AS3-To and AS3-From header fields MUST be present in all AS3 messages and AS3 MDNs.
AS3、およびAS3-からヘッダフィールドは、すべてのAS3メッセージとAS3の開封通知中に存在していなければなりません。
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.
AS3識別子に、このようなEDI識別子/修飾子などのエンティティをマップ実装は上記で定義されたフルセットのサブセットにAS3-TO / AS3-からテキスト値のセットを制約することを選択するかもしれないが、彼らはそのセットを拡張しない場合があります。
If the AS3-From or the AS3-To or the association of the two header values is determined to be invalid or unknown to the receiving system, the receiving system MAY respond with an unsigned MDN containing an explanation of the error if the sending system requested an MDN, but it is not required to return an MDN under those circumstances.
AS3、またはAS3-に又は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バージョンのヘッダは、ヘッダの値が「1.0」ではない場合にのみ必要とされるヘッダです。その目的は、システムは、文書の送信者が文書をパッケージするために使用した本明細書のバージョン（仕様が時間をかけて発展すべきである）を決定することを可能にすることです。バージョンヘッダーが欠落している場合、ユーザエージェントはメッセージを拒否してはなりません。
AS3-Version: 1*DIGIT . 1*DIGIT
AS3-バージョン：1 * DIGIT。 1 * DIGIT
A version header value of "1.1" indicates an implementation can support EDIINT data compression [20]. A user agent MUST NOT send compressed messages to trading partners who do not use a version header of "1.1" or greater.
「1.1」のバージョンのヘッダ値は、実装がEDIINTデータ圧縮[20]をサポートすることができる示しています。ユーザエージェントは、「1.1」以上のバージョンのヘッダーを使用していない取引先に圧縮されたメッセージを送ってはいけません。
FTP has long been viewed as an insecure protocol primarily because of its use of cleartext authentication [3]. This is addressed by RFC 2228 [4], and the use of one of the security mechanisms described therein is strongly encouraged. Specifically, conforming implementations of AS3 SHALL employ FTP client/servers that support the AUTH command described within [4]. While any authentication mechanism based upon [4] MAY be utilized, AUTH TLS (as described in [18]) MUST be supported. (Note that [18] relies on TLS Version 1.0 [13], not Version 1.1 [23].)
FTPは、長い主にクリアテキスト認証の使用の安全性の低いプロトコル[3]のように見てきました。これは、[4] RFC 2228によって対処され、そこに記載されているセキュリティメカニズムのいずれかを使用することが強く推奨されます。具体的には、AS3の適合実装は、内[4]記載のAUTHコマンドをサポートするFTPクライアント/サーバーを使用するものとします。 [4]を利用することができるに基づいて任意の認証メカニズムが、AUTH TLSは、（[18]に記載されているように）サポートしなければなりません。 （[18] TLSバージョン1.0 [13]ではないバージョン1.1 [23]に依存していることに注意してください。）
Large files are handled correctly by the TCP layer. However, the mechanism for compressing data, referenced in Section 2.4.2.2, efficiently reduces transmission requirements for many data types (including both XML and traditional EDI data). Additionally, some FTP implementations support compression as well.
大容量のファイルは、TCP層によって正しく処理されています。しかし、セクション2.4.2.2で参照されるデータを圧縮するためのメカニズムは、効率的に（XML、伝統的なEDIデータの両方を含む）多くのデータ型の伝送要件を低減します。さらに、いくつかのFTPの実装は、同様の圧縮をサポートしています。
An AS3 message MUST contain the following outer headers:
AS3メッセージは、次の外側のヘッダーを含まなければなりません：
AS3-To
AS3-From
Date
Message-ID
Content-Type
An AS3 message OPTIONALLY MAY contain the following outer headers:
AS3メッセージは、オプションで次の外側のヘッダーが含まれる場合があります。
Subject
AS3-Version (assumed to be 1.0 if not present)
Content-Length
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メッセージは処分-NOTIFICATION-にヘッダを含まなければならないと（領収書が署名される場合）処分-NOTIFICATION-オプションヘッダを含むかもしれません。
Additional headers MAY be present but are ignored.
追加のヘッダが存在してもよいが、無視されます。
FTP defines several data structures and character encodings via the STRU[cture] and TYPE commands. AS3 requires the file-structure (default) and the image type. The Content-Transfer-Encoding header SHOULD NOT be used; if the header is present, it SHOULD have a value of binary or 8-bit. The absence of this header or the use of alternate values such as "base64" or "quoted-printable" MUST NOT result in transaction failure. Content transfer encoding of MIME parts within the AS3 message are similarly constrained.
FTPはSTRU [cture]とTYPEコマンドを介して、いくつかのデータ構造と文字エンコーディングを定義します。 AS3は、ファイル構造（デフォルト）と、画像の種類が必要です。コンテンツ転送-Encodingヘッダを使用すべきではありません。ヘッダが存在する場合、それはバイナリまたは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.
RFC 2822のセクション3.6.4で定義されたメッセージIDとオリジナル・メッセージIDは、[15]にフォーマットされている： "<" ID右 "@" ID-左 ">"。メッセージIDの長さは998文字の最大です。メッセージIDは、グローバルに一意である必要があります。 ID-右は送信ホスト環境（例えば、ホスト名）にユニークなものでなければなりません。メッセージを送信する場合は、必ず角括弧が含まれます。角括弧は、メッセージID値の一部ではありません。
NOTE: When creating the Original-Message-Id header in an MDN, always use the exact syntax contained in the original message: do not strip or add "angle brackets".
注：MDNにオリジナル・メッセージ-IDヘッダを作成する場合は、必ず元のメッセージに含まれている正確な構文を使用します。ストリップまたは「角括弧」を追加しないでください。
In order to support non-repudiation of receipt, a signed receipt, based on digitally signing a message disposition notification, is to be implemented by a receiving trading partner's UA. The message disposition notification specified by RFC 3798 is digitally signed by a receiving trading partner as part of a multipart/signed MIME message.
領収書の否認防止をサポートするために、デジタルメッセージ気質通知を署名に基づく署名領収書は、受信した取引相手のUAによって実装されます。 RFC 3798で指定されたメッセージ気質通知は、デジタルマルチパート/署名されたMIMEメッセージの一部として受信取引相手によって署名されます。
The following support for signed receipts is REQUIRED:
署名領収書については、以下のサポートが必要です。
1) The ability to create a multipart/report; where the report-type = disposition-notification.
1）マルチパート/レポートを作成する機能。どこ報告型=気質通知。
2) The ability to calculate a message integrity check (MIC) on the received message. The calculated MIC value will be returned to the sender of the message inside the signed receipt.
2）受信したメッセージにメッセージ完全性チェック（MIC）を計算する能力。計算されたMIC値は、署名された領収書の内部メッセージの送信者に返されます。
3) The ability to create a multipart/signed content with the message disposition notification as the first body part, and the signature as the second body part.
3）第1本体部としてのメッセージ気質通知とマルチパート/署名されたコンテンツを作成する機能、及び第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.
送信された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.
3）受信貿易相手国は、送信者の公開鍵を使ってメッセージに署名を認証します。
The authentication algorithm performs the following:
認証アルゴリズムは、次のことを実行します。
a) The message integrity check (MIC or Message Digest) is decrypted using the sender's public key.
a）のメッセージ完全性チェック（MICまたはメッセージダイジェスト）は、送信者の公開鍵を使って復号化されます。
b) A MIC on the signed contents (the MIME header and encoded EDI object, as per RFC 1767) in the message received is calculated using the same one-way hash function that the sending trading partner used.
b）は、署名されたコンテンツにMIC（送信取引相手が使用したのと同じ一方向ハッシュ関数を用いて算出された受信メッセージにRFC 1767）の通りMIMEヘッダと符号化されたEDIオブジェクト。
c) The MIC extracted from the message that was sent and the MIC calculated using the same one-way hash function that the sending trading partner used are compared for equality.
C）送信されたメッセージ及び使用送信取引パートナが等しいかどうかを比較している同一の一方向ハッシュ関数を用いて計算MICから抽出された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: S/MIME: protocol = "application/pkcs7-signature".
7）マルチパート/署名されたメッセージの第2の部分は、デジタル署名を含んでいます。 S / MIME：プロトコルは=「アプリケーション/ PKCS7署名」を次のようにマルチパート/署名された第二の部分に指定された「プロトコル」オプションがあります。
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コンテンツタイプの一部である場合、MICは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の「受信コンテンツMIC」フィールドで受信されたECインターチェンジ（および1767のMIMEヘッダ）の計算されたMICを返すことによってこれを行います。
3) As an acknowledgment that the receiving trading partner has authenticated the sender of the EDI Interchange.
3）受信貿易相手国は、EDI交換の送信者を認証したことを認めるもの。
4) As a non-repudiation of receipt when the signed MDN is successfully verified by the sender with the receiving trading partner's public key and the returned MIC value inside the MDN is the same as the digest of the original message.
4）署名されたMDNが正常に受信取引相手の公開鍵とMDN内部返さMIC値と、送信者によって確認された受領の否認防止のように、元のメッセージのダイジェストと同じです。
The AS3-MDNs are returned on a separate FTP TCP/IP connection and are a response to an AS3 message.
AS3-開封通知は、別の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
MDN要求ヘッダ=「気質通知から」「：」ftpurl
This syntax is a residual of the use of MDN's in an SMTP transfer. Since this specification is adjusting the functionality from SMTP to
この構文は、SMTP転送におけるMDNの使用の残差です。本明細書は、SMTPからに機能を調整しているので
FTP and retaining as much as possible from the [5] functionality, the ftpurl must be present.
[5]機能からできるだけ多くのFTPと保持、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として指定される<： "FTP：//" URLログイン[ "/" FPATHの[ ";タイプ=" ftptype]]>が存在する必要がありますがftpurlポイント場合、そして、それは無視してもよいです未知の場所へ。未知の場所へftpurl点場合は、MDNが受信されたメッセージの送信者のために知られてftpurlに戻されることが推奨されます。
For requesting MDN-based receipts, the originator supplies the required extension headers that precede the message body.
MDNベースの領収書を要求するため、発信者は、メッセージ本文の前に必要な拡張ヘッダを供給する。
The header "tags" are as follows:
ヘッダ「タグ」以下の通りであります：
A Disposition-notification-to header is added to indicate that a message disposition notification is requested. This header is specified in [6].
処分-通知するヘッダはメッセージ気質通知が要求されていることを示すために追加されます。このヘッダは、[6]で指定されています。
A Message-ID header is added to support message reconciliation, so that an Original-Message-Id value can be returned in the body part of the MDN.
オリジナル・メッセージ-ID値は、MDNの本体部に戻すことができるように、メッセージ-IDヘッダは、メッセージ更新をサポートするために追加されます。
Other headers, especially "Date", SHOULD be supplied; the values of these headers are often mentioned in the human-readable section of an MDN to aid in identifying the original message.
他のヘッダ、特に「日」とは、供給されるべきです。これらのヘッダーの値は、多くの場合、元のメッセージを識別するのを助けるためにMDNの人間可読セクションに記載されています。
Disposition-notification-options identifies characteristics of the message.
配置-通知オプションは、メッセージの特性を識別する。
The following Disposition notification is in accordance with [6].
以下気質通知[6]に従います。
EXAMPLE:
Disposition-notification-to: // Requests the MDN
ftp://host:port/inbox // Location to return MDN
Disposition-notification-options: // The signing options for
MDN
signed-receipt-protocol=optional, pkcs7-signature;
signed-receipt-micalg=optional, sha1, md5
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"
属性は= "符号付き領収書プロトコル" / "符号付き領収-micalg"
So the Disposition-notification-options string could be:
だから、処分通知 - オプション文字列は次のようになります。
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:
MICアルゴリズムの現在サポートされている値は、<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:
以下のように「署名し、領収書プロトコル」パラメータの意味は次のとおりです。
1) The "signed-receipt-protocol" parameter is used to request a signed receipt from the recipient trading partner. The "signed-receipt-protocol" parameter also specifies the format in which the signed receipt should be returned to the requester.
1）「署名されたレシートプロトコル」パラメータは、受信者の取引相手から署名された領収書を要求するために使用されます。 「符号付き領収書プロトコル」パラメータも署名された領収書が要求元に返されるべきフォーマットを指定します。
The "signed-receipt-micalg" parameter is a list of MIC algorithms preferred by the requester for use in signing the returned receipt and calculating the micalg in the Received-content-MIC header.
「符号付き領収-micalg」パラメータは、返された領収書に署名し、受信コンテンツMICヘッダにおけるmicalgを計算する際に使用するためのリクエスタによって好まMICアルゴリズムのリストです。
The list of MIC algorithms should be honored by the recipient from left to right. Both the "signed-receipt-protocol" and the "signed-receipt-micalg" option parameters are REQUIRED when requesting a signed receipt.
MICアルゴリズムのリストは、左から右への受信者が表彰されなければなりません。署名された領収書を要求するとき、「符号付き領収書プロトコル」と「署名されたレシート-micalg」オプションパラメータの両方が必要です。
2) The "importance" attribute of "Optional" is defined in RFC 3798, Section 2.2, and has the following meaning:
2）「オプション」の「重要度」属性は、RFC 3798、セクション2.2で定義され、以下の意味がありますされています。
Parameters with an importance of "Optional" permit a UA that does not understand the particular options parameter to still generate an MDN in response to a request for an MDN. A UA that does not understand the "signed-receipt-protocol" parameter, or the "signed-receipt-micalg" parameter, will obviously not return a signed receipt.
「オプション」の重要性を持つパラメータは、まだMDNの要求に応じて、MDNを生成するために、特定のオプションパラメータを理解していないUAを許可します。 「符号付き領収書プロトコル」パラメータを理解していないUA、または「署名し、領収書micalg」パラメータは、明らかに署名した領収書を返しません。
The importance of "Optional" is used for the signed receipt parameters because it is RECOMMENDED that an MDN be returned to the requesting trading partner even if the recipient could not sign it.
受信者がそれに署名できなかった場合でも、MDNが要求して、取引先に返されることが推奨されているので、「オプション」の重要性は、署名された領収書のパラメータのために使用されています。
The returned MDN will contain information on the disposition of the message as well as on why the MDN could not be signed. See the Disposition field in Section 7.5 for more information.
返されたMDNはメッセージの気質にだけでなく、MDNに署名できなかった理由についての情報が含まれています。詳細については、セクション7.5での処分場を参照してください。
Within an EDI trading relationship, if a signed receipt is expected and is not returned, then the validity of the transaction must be determined by the trading partners. Typically, if a signed receipt is required by the trading relationship and is not received, the transaction will likely not be considered valid.
署名した領収書が予想され、返却されていない場合、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）、明示的に領収書が署名されることを指定するが、受信者は、要求されたプロトコル形式、または要求されたMICアルゴリズムは、いずれかの符号付きまたは符号なしの領収書が返されるべきであるのいずれかをサポートすることができません。
3) When a receipt is requested, explicitly specifying that the receipt be signed, but the recipient is unable to compute the digest (e.g., message was encrypted, and recipient unable to decrypt), then the recipient SHOULD NOT return "Received-content-MIC" in the MDN to the requestor. If the MDN sets the disposition (e.g., "processed/error: decryption-failed") appropriately, then the "Received-content-MIC" may be returned, but the value must be discarded.
領収書が要求された場合3）、明示的に領収書が署名されることを指定しますが、受信者がダイジェストを計算することができない（例えば、メッセージを暗号化し、復号化することができませんでした受信者）、その後、受信者は、「受信-のContentを返すべきではありませんリクエスタにMDNでMIC」。 MDNは、配置を設定した場合（例えば、「処理/エラー：復号化に失敗しました」）を適宜、次いで「受信コンテンツMIC」が返されることがあり、その値は破棄されなければなりません。
4) When a signature is not explicitly requested, or if the signed receipt request parameter is not recognized by the UA, then no receipt, an unsigned receipt, or a signed receipt MAY be returned by the recipient.
4）場合署名が明示的に要求されていない、または署名された領収書の要求パラメータがUAによって認識されない場合、何のレシート、未署名の領収書、または署名された領収書が受信者によって返さなくてもよいです。
5) If a message is received without a request for a receipt, then a receipt (signed or unsigned) MAY be returned.
メッセージを受信するための要求なしで受信された場合5）、次いで、受信（符号付きまたは符号なし）を戻すことができます。
The "Received-content-MIC" MUST be calculated as follows:
以下のように「受信内容-MICは、」計算しなければなりません。
- For any signed messages, the MIC to be returned is calculated on the RFC 1767 MIME header and content. Canonicalization as specified in RFC 1848 MUST be performed before the MIC is calculated, since the sender requesting the signed receipt was also REQUIRED to canonicalize.
- 任意の署名されたメッセージについては、MICは、RFC 1767のMIMEヘッダおよびコンテンツに基づいて計算されて返されます。 MICが計算される前に署名された領収書を要求し、送信者はまた、正規化する必要があったので、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.
- 暗号化され、符号なしのメッセージの場合、MICは、復号化されたRFC 1767のMIMEヘッダおよびコンテンツに基づいて計算されて返されます。 MICが計算される前に復号後のコンテンツは、正規化されなければなりません。
- For unsigned, un-encrypted messages, the MIC MUST be calculated over the message contents prior to Content-Transfer-Encoding and without the MIME or any other RFC 822 [14] headers, since these are sometimes altered or reordered by message transfer agents (MTAs).
- これらは時々変更またはメッセージ転送エージェントによって並べ替えられているため、符号なし、非暗号化メッセージの場合、MICは、前コンテンツ転送エンコードおよびMIMEまたは任意の他のRFC 822 [14]ヘッダーなしでメッセージの内容に渡って計算しなければなりません（のMTA）。
This section defines the format of the AS3 Message Disposition Notification (AS3-MDN).
このセクションでは、AS3メッセージ気質通知（AS3-MDN）のフォーマットを定義します。
The AS3-MDN follows the MDN specification [6] except where noted in this section. The modified entity definitions in this document use the vertical-bar character, '|', to denote a logical "OR" construction. Refer to RFC 2045 for the format of MIME-message-headers.
AS3-MDNは、このセクションで述べた場合を除きMDN仕様[6]に従います。論理「OR」建設を示すために、|「」この文書の修正エンティティ定義は、垂直バーの文字を使用します。 MIMEメッセージ・ヘッダーのフォーマットは、RFC 2045を参照。
The format of the AS3-MDN is
AS3-MDNのフォーマットは、
MDN, no signature
MDN、無署名
-RFC822/2045 -RFC3798 (message/disposition-notification)
-RFC822 / 2045 -RFC3798（メッセージ/気質通知）
MDN, signature
MDN、署名
-RFC822/2045 -RFC1847 (multipart/signed) -RFC3798 (message/disposition-notification) -RFC3851 (application/pkcs7-signature)
-RFC822 / 2045 -RFC1847（マルチパート/署名された）-RFC3798（メッセージ/気質通知）-RFC3851（アプリケーション/ PKCS7署名）
The AS3-MDN-body is formatted as a MIME multipart/report with a report-type of "disposition-notification".
AS3-MDN-体は「処分通知」のレポートタイプとMIMEマルチパート/レポートとしてフォーマットされます。
When unsigned, the transfer-layer ("outermost") entity-headers of the AS3-MDN contain the Content-Type header that specifies a content type of "multipart/report", parameters indicating the report-type, and the value of the outermost multipart boundary.
場合、符号なし、AS3-MDNの転写層（「最外」）エンティティヘッダは、コンテンツの「マルチパート/レポート」のタイプ、レポートのタイプを示すパラメータ、及びの値を指定するContent-Typeヘッダを含みます最も外側のマルチパートの境界。
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の転写層（「最外」）エンティティヘッダはパラメータが計算するのに使用されるアルゴリズムを示し、「マルチパート/署名された」のコンテンツタイプを指定する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の部分は、のように定義される「機械可読」部分であります
AS3-disposition-notification-content = [ reporting-ua-field CRLF ] [ mdn-gateway-field CRLF ] [ original-recipient-field CRLF ] final-recipient-field CRLF [ original-message-id-field CRLF ] AS3-disposition-field CRLF *( failure-field CRLF ) *( error-field CRLF ) *( warning-field CRLF ) *( extension-field CRLF ) [ AS3-received-content-MIC-field CRLF ]
AS3-配置通知内容= [報告-UA-フィールドCRLF] [MDNゲートウェイフィールドCRLF] [元の受信者フィールドCRLF]最終受信者フィールドCRLF [元のメッセージ-IDフィールドCRLF] AS3-配置フィールドCRLF×（不良フィールドCRLF）*（エラーフィールドCRLF）*（警告フィールドCRLF）*（拡張フィールドCRLF）AS3-受信コンテンツMICフィールド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で定義されるように配置通知コンテンツを構築するための規則と同一である[6] RFC 3798処分場は、AS3で置き換えられていることを除き - 処分場及びAS3-受信コンテンツMICフィールドが追加されていること。 RFC 3798処分場及びAS3-配置フィールドの違いを以下に説明します。このドキュメントとRFC 3798との間に差異がある場合は、それらのエンティティ名は「AS3-」を付加することで変更されました。その下のエンティティは、必ずしもさらに、この文書で定義されていないRFC 3798と異なりません。
Refer to RFC 3798 [6] and RFC 4234 [22] for entities that are not further defined in this document.
さらに、この文書で定義されていないエンティティの[22] [6]、RFC 4234、RFC 3798を参照。
AS3-disposition-field = "Disposition:" disposition-mode ";" AS3-disposition-type [ "/" AS3-disposition-modifier]
AS3-処分フィールド= "処分：" 気質モード ";" AS3標準提供[ "/" AS3-可能変更]
disposition-mode = action-mode "/" sending-mode
気質モード=アクションモード「/」送信モード
action-mode = "manual-action" / "automatic-action"
アクション・モード=「マニュアルアクション」/「自動アクション」
sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
送信モードは= "MDN-送信-手動で" / "MDN-送信、自動的に"
AS3-disposition-type = "processed" / "failed"
AS3-処分型= "処理" / "失敗します"
AS3-disposition-modifier = ( "error" / "warning" ) / AS3-disposition-modifier-extension
AS3-規定変更=（ "エラー" / "警告"）/ AS3-規定・変更・拡張
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-処分-修飾-拡張子= "エラー：認証に失敗した" / "エラー：解凍に失敗した" / "エラー：復号化に失敗した" / "エラー：不十分なメッセージセキュリティ" /「エラー：整合性チェック失敗しました"/ "エラー：予期しない処理エラー"/ "警告" AS3-MDN警告記述/ "不良：" AS3-MDN障害記述
AS3-MDN-warning-description = *( TEXT )
AS3-MDN-警告説明= *（TEXT）
AS3-MDN-failure-description = *( TEXT )
AS3-MDN障害記述= *（TEXT）
AS3-received-content-MIC-field = "Received-content-MIC:" encoded-message-digest "," digest-alg-id CRLF
AS3-受信コンテンツMICフィールド= "受信コンテンツMIC：" 符号化されたメッセージ・ダイジェスト "" ダイジェスト-ALG-ID CRLF
encoded-message-digest = 1*( ALPHA / DIGIT / "/" / "+" ) *3"=" ;( i.e. base64( message-digest ) )
エンコードされたメッセージダイジェスト= 1 *（ALPHA / DIGIT / "/" / "+"）* 3 "="（すなわち、BASE64（メッセージダイジェスト））
digest-alg-id = "sha1" / "md5"
ダイジェスト-AL-ID = "ショー1" / "5"
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.
受信したメッセージの整合性が検証された後、「受信内容-MIC」拡張フィールドが設定されています。 MICは、base64エンコードされたメッセージダイジェストのハッシュ関数を用いて受信メッセージにわたって計算されます。このフィールドは、符号なしの領収書のための署名領収書が、オプションのために必要とされます。メッセージダイジェストが計算されるべき上の特定のコンテンツを定義する詳細については、本文書のセクション7.3.1を参照。
The algorithm used to calculate the message digest MUST be the same as the "micalg" value used by the sender in the multipart/signed message. When no signature is received, the message-digest MUST be calculated using the algorithm specified by the "micalg" value in the Disposition-Notification-Options header. When no signature is received and no micalg parameter is provided, then the SHA-1 algorithm MUST be used to calculate the digest. This field is set only when the contents of the message are processed successfully. This field is used in conjunction with the recipient's signature on the MDN in order for the sender to verify non-repudiation of receipt.
メッセージダイジェストを計算するために使用されるアルゴリズムは、マルチパート/署名されたメッセージに送信者によって使用される「micalg」値と同じでなければなりません。何署名が受信されない場合、メッセージダイジェストは処分-NOTIFICATION-オプションヘッダに「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-配置-修飾値、およびユーザ提供*（TEXT）値も大文字と小文字を区別しません。 AS3実装はAS3-MDN警告記述またはAS3-MDN障害記述または任意（オプション）エラー、警告、またはエラーフィールドの値のために供給された値に関する仮定してはなりません。
1. Unlike SMTP, for FTP transactions, Original-Recipient and Final Recipient SHOULD NOT be different. The value in Original-Message-ID MUST match the original Message-ID header value.
1. SMTPとは異なり、FTP取引のために、オリジナル・受信者と最終受信者は異なるべきではありません。オリジナル・メッセージIDの値は、元のメッセージ-IDヘッダの値と一致しなければなりません。
2. Refer to RFC 3462 and RFC 3798 for the formatting of the Content-Type entity-headers for the MDN.
2. MDNのためのContent-Typeエンティティヘッダのフォーマットは、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.
UAが以前にそうするように構成されていたので、MDNが送信されたとき5.「MDN-送ら-自動的に」の送信モードを使用してください。
6. Use a sending-mode of "MDN-sent-manually" when the user explicitly gave permission for this particular MDN to be sent.
ユーザーが明示的に送信されるこの特定のMDNのための許可を与えたとき6.「MDN-送ら-手動」の送信モードを使用してください。
7. The sending-mode "MDN-sent-manually" is ONLY meaningful with "manual-action", not with "automatic-action".
7.送信モード「は、MDN-送信-手動」「自動アクション」で、「マニュアルアクション」でのみ意味がありません。
8. The "failed" disposition type MAY NOT be used for the situation in which there is some problem in processing the message other than interpreting the request for an MDN. The "processed" or other disposition type with appropriate disposition modifiers is to be used in such situations.
8.「失敗」気質タイプがMDNの要求を解釈する以外のメッセージを処理する際に、いくつかの問題が存在する状況のために使用されなくてもよいです。適切な配置の改質剤との「処理」または他の配置タイプが、このような状況で使用されます。
9. An AS3 implementation MUST present to its trading partners an FTP-compliant server interface where inbound documents and MDNs are received.
9. AS3の実装は、その取引先へのインバウンド文書や開封通知が受信されているFTP準拠のサーバ・インタフェースを提示しなければなりません。
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の実装では、貿易相手国の現在設定されているFTPサーバのインターフェースにビジネス文書や開封通知を送ることができなければなりません。
14. An AS3 implementation may imbed FTP client code into their product or use a third-party FTP client.
14. AS3の実装では、自社製品へのFTPクライアントコードを埋め込むか、サードパーティ製のFTPクライアントを使用することができます。
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.
[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.
TPAはTPBが主催埋め込まれたFTPサーバーを使用しているホスティング3.取引先。
[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は、ユーザ設定制御下で送信されている場合は、「配置モード」の最初の部分は、「マニュアルアクション」に設定されるべきです。署名した領収書の要求は常に尊重されなければならないので、利用者は、送信者が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 a user's, an administrator's, or software control.
ユーザは、MDNを送信するための明示的な許可を与えた場合は、「配置モード」の第2の部分は、「MDN-送信-手動」に設定されています。ここでも、ユーザーが明示的に送信者が1を要求したときに署名した領収書を送信することを拒否することが許されてはなりません。 「気質モード」の第2の部分は、EDI UAは関係なく、送信は、ユーザの、管理者、またはソフトウェア制御下にあったかどうかの、自動的にMDNを送信するとき、「MDN-自動的に送信」に設定されています。
Since EDI content is generally handled automatically by the EDI UA, a request for a receipt or signed receipt will generally return the following in the "disposition-field":
EDIコンテンツは、一般的にEDI UAによって自動的に処理されるため、レシートまたは署名された領収書の要求は、一般に「処分場」に次のように返されます。
Disposition: automatic-action/MDN-sent-automatically; processed
処分：自動アクション/-送られ、自動的にMDN;処理されました
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.)
署名された領収書の要求が返される署名された領収書のプロトコル形式、およびメッセージ内容を超えるMICを計算するために使用されるMICアルゴリズムを指定する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.
メッセージの送信者がサポートされていないメッセージの整合性チェック（MIC）アルゴリズムの適用を要求した場合たとえば、この配置型が適用されます。
The "failure:" AS3-disposition-modifier-extension should be used with an implementation-defined description of the failure.
「失敗」AS3-配置-修飾子拡張障害の実装定義の説明に使用されるべきです。
Further information about the failure may be contained in a failure-field. The syntax of the "failed" "disposition-type" is general, allowing the sending of any textual information along with the "failed" "disposition-type". Implementations WILL support any printable textual characters after the Failure disposition-type.
失敗に関するさらなる情報は、故障フィールドに含まれていてもよいです。 「「失敗した」気質型の構文は、「処分型」」失敗した「と一緒に任意のテキスト情報を送信できるように、一般的です」。実装は失敗処分型の後に任意の印刷可能なテキスト文字をサポートします。
For use in Internet EDI, the following "failed" values are pre-defined and MUST be supported:
インターネット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-配置-改質拡張は、特定の、よく知られたエラーのあらかじめ定義された記述にエラーの表示を組み合わせるために使用されるべきです。エラーの詳細については、エラー・フィールドに含まれてもよいです。
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.
「エラー：整合性チェックに失敗した」受信機は、コンテンツの完全性を確認できませんでした。
"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-配置-改質拡張は、警告の実装定義の記述に警告の表示を組み合わせるために使用されるべきです。警告の詳細については、警告・フィールドに含まれていてもよいです。
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バージョン3.1メッセージ仕様で指定された勧告を使用して、公開鍵証明書を交換することを、S / MIMEを使用することをお勧めします。
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で弱い暗号を使用すると、プレーンテキストを送信する上で少し実際のセキュリティを提供しています。しかし、そのようなトリプルDESの仕様とあなたは誰と通信する相手に強力な暗号化機能を発表する能力として、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
証明書の証明書失効リスト（CRL）をチェックする能力 - - 信頼されたCAにありません証明書チェーンのリード - - 証明書は、少なくとも1つのメールアドレスが含まれている場合、証明書にはインターネットメールアドレスは、メッセージの送信者と一致しませんCRLがチェックされている有効期限が切れている - - 無効なCRLを受け取った証明書の期限が切れている - 証明書が失効しています
There are certainly other instances where a certificate may be invalid, and it is the responsibility of the processing software to check them all thoroughly, and to decide what to do if the check fails.
そこ証明書が無効になる可能性のある他のインスタンスは確かであり、それは徹底的にそれらすべてをチェックするために、チェックが失敗した場合に何をすべきかを決定するために、処理ソフトウェアの責任です。
The following certificate types MUST be supported. With URL Without URL Self Certified Certification Authority Certified
次の証明書の種類をサポートしなければなりません。 URL自己認定認証局の認定なしURL付き
The complete certification chain MUST be included in all certificates. All certificate verifications MUST "chain to root". Additionally, the certificate hash should match the hash recomputed by the receiver.
完全な証明書チェーンは、すべての証明書に含まれなければなりません。すべての証明書の検証は、「ルートに連鎖」しなければなりません。また、証明書ハッシュは、受信機によって再計算ハッシュと一致する必要があります。
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[1]フリード、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] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[3]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル"、STD 9、RFC 959、1985年10月。
[4] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 2228, October 1997.
[4]ホロヴィッツ、M.とS.ラント、 "FTPセキュリティ拡張機能"、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]ハーディング、T.、ドラモンド、R.、およびC.シーズー、「インターネット上でのMIMEベースのセキュアなピア・ツー・ピアのビジネスデータ交換」、RFC 3335、2002年9月。
[6] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[6]ハンセン、T.およびG.ボードルイ、 "メッセージ気質通知"、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]ガルビン、J.、マーフィー、S.、クロッカー、S.、およびN.フリード、 "MIMEマルチパートのセキュリティ：マルチパート/署名およびマルチパート/暗号化"、RFC 1847、1995年10月に。
[8] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[8] Klensin、J.、 "簡易メール転送プロトコル"、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.、 "/セキュア多目的インターネットメール拡張（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.は、RFC 3850、2004年7月、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1証明書の取り扱い"。
[12] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[12]ヴォードルイユ、G.、RFC 3462「メールシステムの管理メッセージの報告のための複合/レポートのコンテンツタイプ」、2003年1月。
[13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[13]ダークス、T.とC.アレン、 "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]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
[15] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[15]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[16] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[16]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[17] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[17] Gutmann氏、P.、 "暗号メッセージ構文（CMS）のための圧縮されたデータcontent type"、RFC 3274、2002年6月。
[18] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, October 2005.
[18]フォード・ハッチンソン、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[20] Harding, T., "Compressed Data for EDIINT", Work in Progress, January 2007.
[20]ハーディング、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.、ホフマン、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]クロッカー、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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
Appendix A. Message Examples
付録A.メッセージの例
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のものと指定されたプロトコル定義と矛盾する場合は、例は、間違っています。
A.1. Signed Message Requesting a Signed Receipt
A.1。署名された領収書を要求する署名付きのメッセージ
Date: Wed, 31 Jul 2002 13:34:50 GMT
AS3-Version: 1.0
AS3-From: cyclone
AS3-To: "trading partner"
Message-Id: <200207310834482A70BF63@host.com>
Disposition-Notification-To: ftp://host:port/mdnbox
Disposition-Notification-Options: signed-receipt-
protocol=optional,pkcs7-signature;
signed-receipt-micalg=optional,sha1
Content-Type: multipart/signed; boundary="as3BouNdary1as3";
protocol="application/pkcs7-signature"; micalg=sha1
Content-Length: 3075
--as3BouNdary1as3 Content-Type: application/edi-x12 Content-Disposition: Attachment; filename=rfc1767.dat
--as3BouNdary1as3のContent-Type：アプリケーション/ EDI-X12のContent-処分：添付ファイル;ファイル名= rfc1767.dat
[ISA ...EDI transaction data...IEA...]
[ISA ...トランザクションデータの場合... Iaで...]
--as3BouNdary1as3 Content-Type: application/pkcs7-signature
--as3BouNdary1as3のContent-Type：アプリケーション/ PKCS7署名
[omitted binary pkcs7 signature data] --as3BouNdary1as3--
【省略バイナリPKCS7署名データ] --as3BouNdary1as3--
A.2. MDN for Message A.1 Above
A.2。メッセージA.1上記のためのMDN
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".
RFC 3851 [10]、「/多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様を固定」を参照し、プロトコル=「アプリケーション/ 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 [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]で指定されるように、マルチパート/レポートの第3の本体部分に元のまたは元のメッセージの一部を戻すことは必要とされません。これはオプションの身体の部分です。しかし、この身体の部分が省略されるか空白のままにすることが推奨されます。
Authors' Addresses
著者のアドレス
Terry Harding Axway 8388 E. Hartford Drive, Suite 100 Scottsdale, AZ 85255 USA
テリー・ハーディングAxway 8388 E.ハートフォードドライブ、スイート100スコッツデール、AZ 85255 USA
EMail: tharding@us.axway.com
メールアドレス：tharding@us.axway.com
Richard Scott Axway 8388 E. Hartford Drive, Suite 100 Scottsdale, AZ 85255 USA
リチャード・スコットAxway 8388 E.ハートフォードドライブ、スイート100スコッツデール、AZ 85255 USA
EMail: rscott@us.axway.com
メールアドレス：rscott@us.axway.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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機能のための基金は現在、インターネット協会によって提供されます。