Independent Submission                                   T. Harding, Ed.
Request for Comments: 5402                                         Axway
Category: Informational                                    February 2010
ISSN: 2070-1721
        
                   Compressed Data within an Internet
               Electronic Data Interchange (EDI) Message
        

Abstract

抽象

This document explains the rules and procedures for utilizing compression (RFC 3274) within an Internet EDI (Electronic Data Interchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823.

RFC 3335、4130、および4823で定義されるように、このドキュメントは、メッセージ「AS」インターネットEDI(電子データ交換)内の圧縮(RFC 3274)を利用するためのルールと手順を説明しています。

Status of This Memo

このメモのステータス

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 RFC編集者によって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5402.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5402で取得することができます。

IESG Note

IESG注意

The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work. This RFC is not a candidate for any level of Internet Standard. Readers of this RFC should exercise caution in evaluating its value for implementation and deployment.

このRFCの内容は、IETFによって考慮一度だったので、それが進行または公開されたIETF仕事で現在IETFの作業に似ていてもよいです。このRFCはインターネットStandardのどんなレベルの候補ではありません。このRFCの読者は実現と展開のためにその値を評価する際に警戒する必要があります。

Copyright Notice

著作権表示

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

このドキュメントの発行日に有効な:(trustee.ietf.org/license-info HTTP)この文書では、BCP 78とIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。

1. Introduction
1. はじめに

Historically, electronic messages produced by systems following the guidelines as outlined in the IETF EDIINT Working Group specifications AS1 [AS1], AS2 [AS2], and AS3 [AS3] did not have a way to provide a standardized transport neutral mechanism for compressing large payloads. However, with the development of RFC 3274, "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", we now have a transport-neutral mechanism for compressing large payloads.

歴史的に、IETF EDIINTワーキンググループ仕様AS1 [AS1]、AS2 [AS2]、およびAS3 [AS3]に概説されているようなガイドラインを以下のシステムで生成する電子メールには、大きなペイロードを圧縮するための標準化されたトランスポート中立のメカニズムを提供する方法がありませんでした。しかし、RFC 3274、「暗号メッセージ構文(CMS)のための圧縮されたデータcontent type」の開発を、我々は今、大きなペイロードを圧縮するためのトランスポート中立のメカニズムを持っています。

A typical EDIINT 'AS' message is a multi-layered MIME message, consisting of one or more of the following: payload layer, signature layer, and/or encryption layer. When an 'AS' message is received, a Message Integrity Check (MIC) value must be computed based upon defined rules within the EDIINT 'AS' RFCs and must be returned to the sender of the message via a Message Disposition Notification (MDN).

ペイロード層、署名層、及び/又は暗号化層:メッセージ「AS」の典型的なEDIINTは、以下の一つ以上からなる多層MIMEメッセージです。 「AS」メッセージを受信すると、メッセージ整合性チェック(MIC)値は、RFCの「AS」EDIINT内で定義されたルールに基づいて計算されなければならず、メッセージ気質通知(MDN)を介してメッセージの送信者に返さなければなりません。

The addition of a new compression layer will require this document to outline new procedures for building/layering 'AS' messages and computing a MIC value that is returned in the MDN receipt.

新しい圧縮層の追加は、メッセージ「と」/レイヤーを構築し、MDN領収書に返されたMIC値を計算するための新しい手順の概要を説明するために、この文書が必要になります。

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 [RFC2119].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。

2. Compressed Data MIME Layer
2.圧縮データMIMEレイヤー

The compressed-data CMS (Cryptographic Message Syntax) MIME entity as described in [COMPRESSED-DATA] may encapsulate a MIME entity that consists of either an unsigned or signed business document.

圧縮データCMS(暗号メッセージ構文)MIMEエンティティ[圧縮データ]に記載のいずれかの符号なしまたは署名されたビジネス文書から成るMIMEエンティティをカプセル化してもよいです。

Implementers are to follow the appropriate specifications identified in the "MIME Media Types" registry [MIME-TYPES] maintained by IANA for the type of object being packaged. For example, to package an XML object, the MIME media type of "application/xml" is used in the Content-Type MIME header field and the specifications for enveloping the object are contained in [XMLTYPES].

実装者は、包装されるオブジェクトのタイプにIANAによって維持「MIMEメディアタイプ」レジストリ[MIMEタイプ]で識別された適切な仕様に従うことです。例えば、XMLオブジェクトをパッケージ化するために、「アプリケーション/ XML」のMIMEメディアタイプは、Content-TypeのMIMEヘッダフィールドに使用され、オブジェクトを包むための仕様は、[のXMLType]に含まれています。

MIME entity example:

MIMEエンティティの例:

Content-type: application/xml; charset="utf-8"

コンテンツタイプ:アプリケーション/ xmlの; charset = "UTF-8" を

<?xml version="1.0" encoding="UTF-8"?> <!-- sample xml document -->

<?xml version = "1.0" エンコード= "UTF-8"?> <! - サンプルXML文書 - >

The MIME entity will be compressed using [ZLIB] and placed inside a CMS compressed-data object as outlined in [COMPRESSED-DATA]. The compressed-data object will be MIME encapsulated according to details outlined in [S/MIME3.1], RFC 3851, Section 3.5.

[圧縮データ]に概説されるようにMIMEエンティティは、[ZLIB]を用いて圧縮し、CMS圧縮データオブジェクトの内部に配置されます。圧縮されたデータオブジェクトは、MIME [S / MIME3.1]に概説詳細、RFC 3851、セクション3.5に従ってカプセル化されるであろう。

Example:

例:

Content-Type: application/pkcs7-mime; smime-type=compressed-data; name=smime.p7z Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7z

コンテンツタイプ:アプリケーション/ PKCS7-MIME; SMIME型=圧縮データ。名前= smime.p7zコンテンツ転送 - エンコード:base64でコンテンツディスポジション:添付ファイル;ファイル名= smime.p7z

MIAGCyqGSIb3DQEJEAEJoIAwgAIBADANBgsqhkiG9w0BCRADCDCABgkqhkiG9w0BBwGg Hnic7ZRdb9owFIbvK/k/5PqVYPFXGK12YYyboVFASSp1vQtZGiLRACZE49/XHoUW7S/0 fU5ivWnasml72XFb3gb5druui7ytN803M570nii7C5r8tfwR281hy/p/KSM3+jzH5s3+ P3VT3QbLusnt8WPIuN5vN/vaA2+DulnXTXkXvNTr8j8ouZmkCmGI/UW+ZS/C8zP0bz2d UEk2M8mlaxjRMByAhZTj0RGYg4TvogiRASROsZgjpVcJCb1KV6QzQeDJ1XkoQ5Jm+C5P v+ORAcshOGeCcdFJyfgFxdtCdEcmOrbinc/+BBMzRThEYpwl+jEBpciSGWQkI0TSlREm SGLuESm/iKUFt1y4XHBO2a5oq0IKJKWLS9kUZTA7vC5LSxYmgVL46SIWxIfWBQd6Adrn vGxVibLqRCtIpp4g2qpdtqK1LiOeolpVK5wVQ5P7+QjZAlrh0cePYTx/gNZuB9Vhndtg W9ogK+3rnmg3YWygnTuF5GDS+Q/jIVLnCcYZFc6Kk/+c80wKwZjwdZIqDYWRH68MuBQS 3CAaYOBNJMliTl0X7eV5DnoKIFSKYdj3cRpD/cK/JWTHJRe76MUXnfBW8m7Hd5zhQ4ri +kV1/3AGSlJ32bFPd2BsQD8uSzIx6lObkjdz95c0AAAAAAAAAAAAAAAA

MIAGCyqGSIb3DQEJEAEJoIAwgAIBADANBgsqhkiG9w0BCRADCDCABgkqhkiG9w0BBwGg Hnic7ZRdb9owFIbvK / K / 5PqVYPFXGK12YYyboVFASSp1vQtZGiLRACZE49 / XHoUW7S / 0 fU5ivWnasml72XFb3gb5druui7ytN803M570nii7C5r8tfwR281hy / P / KSM3 + jzH5s3 + P3VT3QbLusnt8WPIuN5vN / vaA2 + DulnXTXkXvNTr8j8ouZmkCmGI / UW + ZS / C8zP0bz2d UEk2M8mlaxjRMByAhZTj0RGYg4TvogiRASROsZgjpVcJCb1KV6QzQeDJ1XkoQ5Jm + C5PのV + ORAcshOGeCcdFJyfgFxdtCdEcmOrbinc / + BBMzRThEYpwl + jEBpciSGWQkI0TSlREm SGLuESm / iKUFt1y4XHBO2a5oq0IKJKWLS9kUZTA7vC5LSxYmgVL46SIWxIfWBQd6Adrn vGxVibLqRCtIpp4g2qpdtqK1LiOeolpVK5wVQ5P7 + QjZAlrh0cePYTx / gNZuB9Vhndtg W9ogK + 3rnmg3YWygnTuF5GDS + Q / jIVLnCcYZFc6Kk / + c80wKwZjwdZIqDYWRH68MuBQS 3CAaYOBNJMliTl0X7eV5DnoKIFSKYdj3cRpD / CK / JWTHJRe76MUXnfBW8m7Hd5zhQ4ri + KV1 / 3AGSlJ32bFPd2BsQD8uSzIx6lObkjdz95c0AAAAAAAAAAAAAAAA

Note: Content-Transfer-Encoding of base64 would only be required if the compressed-data MIME bodypart is transferred via a 7-bit protocol like SMTP and is visible in the outer layer of the MIME message. If the compressed-data MIME bodypart is placed inside of an encrypted MIME bodypart, content-transfer-encoding would not be required on the compressed-data MIME bodypart, but would be required on the encrypted MIME bodypart.

注:圧縮されたデータのMIMEボディ部は、SMTPのような7ビット・プロトコルを介して転送され、MIMEメッセージの外側の層に表示されている場合BASE64のコンテンツ転送エンコードのみが必要とされるであろう。圧縮データのMIMEボディ部は、暗号化されたMIMEボディ部の内側に配置されている場合、コンテンツ転送符号化は、圧縮データのMIMEボディ部に必要とされないだろうが、暗号化されたMIMEボディ部に必要とされるであろう。

3. Structure of an EDI MIME Compressed Message
EDI MIME圧縮されたメッセージの3構造

When compressing a document that will be signed, the application MAY compress the innermost MIME body before signing (see Sections 3.2 and 3.5), or it MAY compress the outer multipart/signed MIME body (see Sections 3.3 and 3.6), but it MUST NOT do both within the same document. The receiving application MUST support both methods of compression when unpackaging an inbound document.

署名された文書を圧縮するとき、アプリケーションは(セクション3.2および3.5を参照)署名する前に、最も内側のMIME本体を圧縮することができる、又はそれは外側のマルチパートを圧縮することができる/ MIME本体(セクション3.3および3.6を参照)に署名し、それはNOT MUST同じドキュメント内の両方を行います。インバウンド文書を開梱時に受信側アプリケーションは、圧縮の両方の方法をサポートしなければなりません。

Note: The following sections (3.1 - 3.6) show the individual layers of a properly formatted EDI MIME message with a compressed data layer. Please refer to the appropriate RFCs for the proper construction of the resulting MIME message. "application/xxxxxxx" is used to indicate an application media subtype.

注:以下のセクション(3.1から3.6)は、圧縮されたデータ層を適切にフォーマットされたEDIのMIMEメッセージの個々の層を示します。結果のMIMEメッセージを適切に構築するための適切なのRFCを参照してください。 「アプリケーション/ XXXXXXXは、」アプリケーションメディアサブタイプを示すために使用されます。

3.1. No Encryption, No Signature
3.1. 暗号化なし、署名なし

-RFC5322/2045 -[COMPRESSED-DATA](application/pkcs7-mime) -[MIME-TYPES](application/xxxxxxx)(compressed)

/ 2045 -RFC5322 - [圧縮データ(アプリケーション/ PKCS7-MIME) - [MIMEタイプ(アプリケーション/ XXXXXXX)(圧縮)

This section shows the layers of an unsigned, unencrypted compressed message. The first line indicates that the MIME message conforms to [RFC5322] and [RFC2045] with a Content-Type of application/pkcs7-mime. Within the pkcs7-mime entity is a compressed MIME entity containing the electronic business document.

このセクションでは、符号なし、暗号化されていない圧縮メッセージの層を示しています。最初の行は、MIMEメッセージがアプリケーション/ PKCS7-MIMEのコンテンツタイプと[RFC5322]及び[RFC2045]に準拠していることを示しています。 PKCS7-MIMEエンティティ内の電子ビジネス文書を含む圧縮されたMIMEエンティティです。

3.2. No Encryption, Signature
3.2. 暗号化なし、署名

-RFC5322/2045 -[RFC1847] (multipart/signed) -[COMPRESSED-DATA](application/pkcs7-mime) -[MIME-TYPES](application/xxxxxxx)(compressed) -RFC3851 (application/pkcs7-signature)

/ 2045 -RFC5322 - [RFC1847](マルチは/署名された) - [圧縮データ(アプリケーション/ PKCS7-MIME) - [MIMEタイプ(アプリケーション/ XXXXXXX)(圧縮)-RFC3851(アプリケーション/ PKCS7署名)

This section shows the layers of a signed, unencrypted compressed message where the payload is compressed before being signed.

このセクションでは、ペイロードが署名される前に圧縮されて署名された、暗号化されていない圧縮メッセージの層を示しています。

3.3. No Encryption, Signature
3.3. 暗号化なし、署名

-RFC5322/2045 -[COMPRESSED-DATA](application/pkcs7-mime) -[RFC1847] (multipart/signed)(compressed) -[MIME-TYPES](application/xxxxxxx)(compressed) -RFC3851 (application/pkcs7-signature)(compressed)

/ 2045 -RFC5322 - [圧縮データ(アプリケーション/ PKCS7-MIME) - [RFC1847](圧縮)(マルチパート/署名された) - [MIMEタイプ(アプリケーション/ XXXXXXX)(圧縮)-RFC3851(アプリケーション/ pkcs7-署名)(圧縮)

This section shows the layers of a signed, unencrypted compressed message where a signed payload is compressed.

このセクションでは、署名されたペイロードが圧縮されている署名暗号化されていない圧縮メッセージの層を示しています。

3.4. Encryption, No Signature
3.4. 暗号化、署名なし

-RFC5322/2045 -RFC3851 (application/pkcs7-mime) -[COMPRESSED-DATA](application/pkcs7-mime) (encrypted) -[MIME-TYPES](application/xxxxxxx)(compressed)(encrypted)

-RFC5322 / 2045 -RFC3851(アプリケーション/ PKCS7-MIME) - [圧縮データ(アプリケーション/ PKCS7-MIME)(暗号化) - [MIMEタイプ(アプリケーション/ XXXXXXX)(圧縮)(暗号化)

This section shows the layers of an unsigned, encrypted compressed message where the payload is compressed before it is encrypted.

このセクションでは、それが暗号化される前に、ペイロードが圧縮され、符号なし、暗号化され圧縮されたメッセージの層を示しています。

3.5. Encryption, Signature
3.5. 暗号化、署名

-RFC5322/2045 -RFC3851 (application/pkcs7-mime) -[RFC1847] (multipart/signed) (encrypted) -[COMPRESSED-DATA](application/pkcs7-mime) (encrypted) -[MIME-TYPES](application/xxxxxxx) (compressed)(encrypted) -RFC3851 (application/pkcs7-signature) (encrypted)

-RFC5322 / 2045 -RFC3851(アプリケーション/ PKCS7-MIME) - [RFC1847](マルチパート/署名された)(暗号化) - [圧縮データ(アプリケーション/ PKCS7-MIME)(暗号化) - [MIMEタイプ(アプリケーション/ -RFC3851)暗号化された()XXXXXXX)(圧縮(アプリケーション/ PKCS7署名)(暗号化)

This section shows the layers of a signed, encrypted compressed message where the payload is compressed before being signed and encrypted.

このセクションでは、ペイロードが署名および暗号化される前に圧縮されて署名された、暗号化され圧縮されたメッセージの層を示しています。

3.6. Encryption, Signature
3.6. 暗号化、署名

-RFC5322/2045 -RFC3851 (application/pkcs7-mime) -[COMPRESSED-DATA](application/pkcs7-mime) (encrypted) -[RFC1847] (multipart/signed) (compressed)(encrypted) -[MIME-TYPES](application/xxxxxxx) (compressed)(encrypted) -RFC3851 (application/pkcs7-signature)(compressed)(encrypted)

-RFC5322 / 2045 -RFC3851(アプリケーション/ PKCS7-MIME) - [圧縮データを(アプリケーション/ PKCS7-MIME)(暗号化) - [RFC1847](マルチパート/署名された)(圧縮)(暗号化) - [MIMEタイプ] (アプリケーション/ XXXXXXX)(圧縮)(暗号化)-RFC3851(アプリケーション/ PKCS7署名)(圧縮)(暗号化)

This section shows the layers of a signed, encrypted compressed message where the payload is signed before being compressed and encrypted.

このセクションでは、ペイロードが圧縮され、暗号化される前に署名され署名され、暗号化され圧縮されたメッセージの層を示しています。

4. MIC Calculations for Compressed Messages Requesting Signed Receipts
署名された領収書を要求圧縮されたメッセージ4. MICの計算
4.1. MIC Calculation for Signed Message
4.1. 署名されたメッセージのMICの計算

For any signed message, the MIC to be returned is calculated over the same data that was signed in the original message as per [AS1]. The signed content will be a MIME bodypart that contains either compressed or uncompressed data.

いずれかの署名されたメッセージの場合、MICは、[AS1]に従って元のメッセージに署名された同一のデータ上で計算され返されます。署名したコンテンツは、圧縮または非圧縮のいずれかのデータが含まれているMIMEボディ部になります。

4.2. MIC Calculation for Encrypted, Unsigned Message
4.2. 暗号化され、符号なしのメッセージのためのMICの計算

For encrypted, unsigned messages, the MIC to be returned is calculated over the uncompressed data content including all MIME header fields and any applied Content-Transfer-Encoding.

暗号化され、符号なしのメッセージの場合、返されるMICは、すべてのMIMEヘッダフィールドを含む非圧縮データの内容に対して計算され、任意のコンテンツ転送エンコードを適用します。

4.3. MIC Calculation for Unencrypted, Unsigned Message
4.3. 暗号化されていない、未署名のメッセージのためのMICの計算

For unsigned, unencrypted messages, the MIC is calculated over the uncompressed data content including all MIME header fields and any applied Content-Transfer-Encoding.

未署名、暗号化されていないメッセージの場合、MICは、すべてのMIMEヘッダフィールドを含む非圧縮データのコンテンツにわたって計算され、任意のは、コンテンツ転送エンコード適用しました。

5. Error Disposition Modifier
5.レイアウトの編集エラー

For a received message where a receipt has been requested and decompression fails, the following disposition modifier will be returned in the signed MDN.

領収書が要求されたと解凍に失敗した受信メッセージの場合は、以下の気質修飾子は署名MDNに返されます。

"Error: decompression-failed" - the receiver could not decompress the message

「エラー:解凍に失敗した」 - 受信者がメッセージを解凍できませんでした

6. EDIINT Version Header Field
6. EDIINTバージョンヘッダーフィールド

Any application that supports the compression methods outlined within this document MUST use a version identifier value of "1.1" or greater within the AS2 or AS3 Version header field as describe in [AS2] and [AS3].

[AS2]と[AS3]で説明したように、この文書内概説圧縮方法をサポートする任意のアプリケーションは、AS2またはAS3バージョンのヘッダフィールド内に「1.1」以上のバージョン識別子の値を使用しなければなりません。

7. Compression Formats
7.圧縮形式

Implementations MUST support ZLIB [ZLIB], which utilizes DEFLATE [DEFLATE].

実装はDEFLATE [DEFLATE]を利用しZLIB [ZLIB]を、サポートしなければなりません。

8. Security Considerations
8.セキュリティの考慮事項

This document is not concerned with security, except for any security concerns mentioned in the referenced RFCs.

この文書は、参照のRFCに記載されたすべてのセキュリティ上の問題を除いて、セキュリティに関係していません。

9. Normative References
9.引用規格

[AS1] Harding, T., Drummond, R., and C. Shih, "MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet", RFC 3335, September 2002.

[AS1]ハーディング、T.、ドラモンド、R.、およびC.シーズー、「MIMEベースのセキュアなピアツーピアのビジネスデータ交換をインターネット上で」、RFC 3335、2002年9月。

[AS2] Moberg, D. and R. Drummond, "MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)", RFC 4130, July 2005.

[AS2] Moberg、D.およびR.ドラモンド、 "MIMEベースのセキュアなピアツーピアHTTPを使用してビジネスデータ交換、適用ステートメント2(AS2)"、RFC 4130、2005年7月。

[AS3] Harding, T. and R. Scott, "FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet", RFC 4823, April 2007.

[AS3]ハーディング、T.およびR.スコット、「インターネット上でのセキュアなピア・ツー・ピアのビジネスデータ交換のためのFTP転送」、RFC 4823、2007年4月。

[ZLIB] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.

【ZLIB]ドイツ、P.及びJ-L。 Gailly氏、 "ZLIB圧縮データフォーマット仕様バージョン3.3"、RFC 1950、1996年5月。

[DEFLATE] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.

[DEFLATE]ドイツ、P.、 "DEFLATE圧縮データフォーマット仕様バージョン1.3"、RFC 1951、1996年5月。

[MIME-TYPES] IANA, "MIME Media Types" registry, available from http://www.iana.org.

http://www.iana.orgから入手できる[MIME-TYPES] IANA、 "MIMEメディアタイプ" レジストリ、。

[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.

[RFC1847]ガルビン、J.、マーフィー、S.、クロッカー、S.、およびN.フリード、 "セキュリティマルチパートMIMEのために:マルチパート/署名およびマルチパート/暗号化"、RFC 1847、1995年10月。

[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

[RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション(MIME)第一部:インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.

[RFC5322]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 5322、2008年10月。

[S/MIME3.1] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.

[S / MIME3.1] Ramsdell、B.、およびS.ターナーは、RFC 5751、2010年1月、 "/多目的インターネットメール拡張(S / MIME)バージョン3.2メッセージ仕様安全"。

[XMLTYPES] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.

[のXMLType]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。

[COMPRESSED-DATA] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.

[圧縮データ] Gutmann氏、P.、 "暗号メッセージ構文(CMS)のための圧縮されたデータcontent type"、RFC 3274、2002年6月。

10. Acknowledgments
10.謝辞

A number of the members of the EDIINT Working Group have also worked very hard and contributed to this document. The following people have made direct contributions to this document:

EDIINTワーキンググループのメンバーの数も非常に懸命に働いたと、この文書に貢献しています。次の人は、この文書に直接貢献をしました。

David Fischer, Dale Moberg, Robert Asis, and everyone involved in the AS1, AS2 Interop testing during 2002.

デビッド・フィッシャー、デイルMoberg、ロバート・アシス、および2002年AS1、AS2の相互運用テストに関わるすべての人。

Author's Address

著者のアドレス

Terry Harding Axway Scottsdale, Arizona USA

テリー・ハーディングAxwayスコッツデール、アリゾナ州、アメリカ

EMail: tharding@us.axway.com

メールアドレス:tharding@us.axway.com