Compressed Data within an Internet Electronic Data Interchange (EDI) Message
RFC 5402

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 12

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.

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.

   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.

IESG Note

   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.

Copyright Notice

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

   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

Harding                       Informational                     [Page 1]
RFC 5402       Compressed Data in an Internet EDI Message  February 2010

   carefully, as they describe your rights and restrictions with respect
   to this document.

1.  Introduction

   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.

   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).

   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.

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

2.  Compressed Data MIME Layer

   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.

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

   MIME entity example:

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

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

Harding                       Informational                     [Page 2]
RFC 5402       Compressed Data in an Internet EDI Message  February 2010

   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.

   Example:

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

   MIAGCyqGSIb3DQEJEAEJoIAwgAIBADANBgsqhkiG9w0BCRADCDCABgkqhkiG9w0BBwGg