[要約] 要約： RFC 5402は、インターネット電子データ交換（EDI）メッセージ内の圧縮データに関する標準仕様です。このRFCの目的は、EDIメッセージの効率的な圧縮と伝送を可能にするための手法を提供することです。目的： 1. インターネットEDIメッセージ内のデータを効率的に圧縮する方法を提供する。 2. 圧縮されたデータの伝送に関する標準化を行う。 3. EDIメッセージの処理と効率を向上させる。
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
インターネット電子データインターチェンジ（EDI）メッセージ内の圧縮データ
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.
このドキュメントでは、RFCS 3335、4130、および4823で定義されているように、インターネット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エディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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は、インターネット標準のレベルの候補者ではありません。このRFCの読者は、実装と展開の価値を評価する際に注意する必要があります。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（http：trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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）の圧縮データコンテンツタイプ」の開発により、大きなペイロードを圧縮するための輸送中立メカニズムがあります。
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).
典型的なediint 'as'メッセージは、ペイロード層、署名層、および/または暗号化層の1つ以上で構成される多層Mimeメッセージです。「as」メッセージが受信される場合、メッセージ整合性チェック（MIC）値は、ediint内の定義されたルール '' 'rfcsに基づいて計算する必要があり、メッセージ処分通知（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領収書で返されるマイク値を計算する必要があります。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
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.
[圧縮-Data]に記載されているように、圧縮されたDATA 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オブジェクトをパッケージ化するために、MIMEメディアタイプの「アプリケーション/XML」がコンテンツタイプのMIMEヘッダーフィールドで使用され、オブジェクトを包むための仕様は[XMLTYPES]に含まれています。
MIME entity example:
MIMEエンティティの例：
Content-type: application/xml; charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?> <!-- sample xml document --> 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.
<？xml version = "1.0" encoding = "utf-8"？> <！ - サンプルxmlドキュメント - > mimeエンティティは[zlib]を使用して圧縮され、[圧縮されたデータ]。圧縮されたDATAオブジェクトは、[S/MIME3.1]、RFC 3851、セクション3.5で概説されている詳細に従ってMIMEカプセル化されます。
Example:
例：
Content-Type: application/pkcs7-mime; smime-type=compressed-data;
name=smime.p7z
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=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
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.
注：Base64のコンテンツ転移エンコードは、圧縮されたDATA MIMEボディパートがSMTPのような7ビットプロトコルを介して転送され、MIMEメッセージの外層に表示される場合にのみ必要です。圧縮されたダタMIMEボディパートが暗号化されたMIMEボディパートの内側に配置されている場合、圧縮されたDATA Mime BodyPartではコンテンツトランスファーエンコードは必要ありませんが、暗号化されたMime BodyPartでは必要です。
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.
署名されるドキュメントを圧縮する場合、アプリケーションは署名する前に最も内側のmimeボディを圧縮することがあります（セクション3.2および3.5を参照）、または外側のマルチパート/署名されたマイムボディ（セクション3.3および3.6を参照）を圧縮することがありますが、同じドキュメント内で両方を実行します。受信アプリケーションは、インバウンドドキュメントを開梱するときに両方の圧縮方法をサポートする必要があります。
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」は、アプリケーションメディアサブタイプを示すために使用されます。
-RFC5322/2045
-[COMPRESSED-DATA](application/pkcs7-mime)
-[MIME-TYPES](application/xxxxxxx)(compressed)
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メッセージが[RFC5322]および[RFC2045]にコンテンツタイプのアプリケーション/PKCS7-MIMEに適合することを示しています。PKCS7-MIMEエンティティ内には、電子ビジネスドキュメントを含む圧縮MIMEエンティティがあります。
-RFC5322/2045
-[RFC1847] (multipart/signed)
-[COMPRESSED-DATA](application/pkcs7-mime)
-[MIME-TYPES](application/xxxxxxx)(compressed)
-RFC3851 (application/pkcs7-signature)
This section shows the layers of a signed, unencrypted compressed message where the payload is compressed before being signed.
このセクションでは、署名される前にペイロードが圧縮される署名された、暗号化されていない圧縮メッセージの層を示します。
-RFC5322/2045
-[COMPRESSED-DATA](application/pkcs7-mime)
-[RFC1847] (multipart/signed)(compressed)
-[MIME-TYPES](application/xxxxxxx)(compressed)
-RFC3851 (application/pkcs7-signature)(compressed)
This section shows the layers of a signed, unencrypted compressed message where a signed payload is compressed.
このセクションでは、署名された、暗号化されていない圧縮メッセージの層が、署名されたペイロードが圧縮されていることを示しています。
-RFC5322/2045
-RFC3851 (application/pkcs7-mime)
-[COMPRESSED-DATA](application/pkcs7-mime) (encrypted)
-[MIME-TYPES](application/xxxxxxx)(compressed)(encrypted)
This section shows the layers of an unsigned, encrypted compressed message where the payload is compressed before it is encrypted.
このセクションでは、ペイロードが暗号化される前に圧縮される署名されていない暗号化された圧縮メッセージの層を示します。
-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)
This section shows the layers of a signed, encrypted compressed message where the payload is compressed before being signed and encrypted.
このセクションでは、署名されて暗号化される前にペイロードが圧縮される署名された暗号化された圧縮メッセージのレイヤーを示します。
-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)
This section shows the layers of a signed, encrypted compressed message where the payload is signed before being compressed and encrypted.
このセクションでは、圧縮されて暗号化される前にペイロードが署名されている署名された暗号化された圧縮メッセージのレイヤーを示します。
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.
署名されたメッセージの場合、返されるマイクは、[AS1]に従って元のメッセージで署名されたのと同じデータで計算されます。署名されたコンテンツは、圧縮データまたは非圧縮データのいずれかを含むMIMEボディパートになります。
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.
暗号化された、署名されていないメッセージの場合、返されるマイクは、すべてのMIMEヘッダーフィールドや適用されたコンテンツ移動エンコードを含む非圧縮データコンテンツで計算されます。
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ヘッダーフィールドや適用されたコンテンツ移動エンコードを含む非圧縮データコンテンツで計算されます。
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
「エラー：減圧症」 - 受信者はメッセージを解凍できませんでした
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」以下のバージョン識別子値を使用する必要があります。
Implementations MUST support ZLIB [ZLIB], which utilizes DEFLATE [DEFLATE].
実装は、deflate [deflate]を利用するZlib [Zlib]をサポートする必要があります。
This document is not concerned with security, except for any security concerns mentioned in the referenced RFCs.
参照されているRFCSで言及されているセキュリティ上の懸念を除いて、このドキュメントはセキュリティに関係していません。
[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] Harding、T.、Drummond、R。、およびC. Shih、「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. Drummond、「HTTPを使用したMIMEベースのセキュアピアツーピアビジネスデータインターチェンジ、Applicability Statement 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] Harding、T。and R. Scott、「インターネット上で安全なピアツーピアのビジネスデータ交換のための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] Deutsch、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] Deutsch、P。、「Deflate圧縮データ形式仕様バージョン1.3」、RFC 1951、1996年5月。
[MIME-TYPES] IANA, "MIME Media Types" registry, available from http://www.iana.org.
[mime-types] iana、 "mime media types"レジストリ、http：//www.iana.orgから入手可能。
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[RFC1847] Galvin、J.、Murphy、S.、Crocker、S。、およびN. Freed、「Mimeのセキュリティマルチパート：MultiPart/SignedおよびMultiPart/暗号化」、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] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P.、ed。、「インターネットメッセージ形式」、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. Turner、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.2メッセージ仕様」、RFC 5751、2010年1月。
[XMLTYPES] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[XMLTYPES] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[COMPRESSED-DATA] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[Compressed-Data] Gutmann、P。、「暗号化メッセージ構文（CMS）の圧縮データコンテンツタイプ」、RFC 3274、2002年6月。
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.
デビッド・フィッシャー、デール・モーバーグ、ロバート・アシス、および2002年のAS1、AS2間試験に参加したすべての人。
Author's Address
著者の連絡先
Terry Harding Axway Scottsdale, Arizona USA
テリーハーディングアックスウェイスコッツデール、アリゾナアメリカ
EMail: tharding@us.axway.com