Draft              Multiple Attachments for EDIINT          June 2008 
 
 
   Private Working Group                                     K. Meadors 
   Internet-Draft                                   Drummond Group Inc. 
   Expires: December 2008                                     June 2008 
   Target Category: Informational                                       
                                                                        
                                                                        
    
    
                     Multiple Attachments for EDI-INT 
             draft-meadors-multiple-attachments-ediint-06.doc 
    
Status of this Memo 
    
   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of BCP 79. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that      
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.html 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html. 
    
   Any questions, comments, and reports of defects or ambiguities in 
   this specification may be sent to the mailing list for the EDIINT 
   working group of the IETF Trust, using the address <ietf-
   ediint@imc.org>. Requests to subscribe to the mailing list should be 
   addressed to <ietf-ediint-request@imc.org>. 
    
Copyright Notice 
    
   Copyright (C) The IETF Trust (2008). 
    
Abstract 
    
   The EDIINT AS1, AS2 and AS3 message were designed specifically for 
   the transport of EDI documents. Since multiple interchanges could be 
   placed within a single EDI document, there was not a need for sending 
 
 
Meadors                 Expires - December 2008               [Page 1] 
Draft               Multiple Attachments for EDIINT          June 2008 
 
 
   multiple EDI documents in a single message. As adoption of EDI-INT 
   grew, other uses developed aside from single EDI document transport. 
   Some transactions required multiple attachments to be interpreted 
   together and stored in a single message. This informational draft 
   describes how multiple documents, including non-EDI payloads, can be 
   attached and transmitted in a single EDI-INT transport message. The 
   attachments are stored within the MIME Multipart/Related structure. A 
   minimal list of content-types to be supported as attachments is 
   provided. 
    
Conventions used in 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. 
    
Feedback Instructions 
    
   NOTE TO RFC EDITOR:  This section should be removed by the RFC editor 
   prior to publication. 
    
   If you want to provide feedback on this draft, follow these 
   guidelines: 
    
   -Send feedback via e-mail to kyle@drummondgroup.com, with "EDIINT 
   Multiple Attachments" in the Subject field. 
    
   -Be specific as to what section you are referring to, preferably 
   quoting the portion that needs modification, after which you state 
   your comments. 
    
   -If you are recommending some text to be replaced with your suggested 
   text, again, quote the section to be replaced, and be clear on the 
   section in question. 
    
 
Table of Contents 
    
   1. Introduction...................................................3 
   2. Using Multiple-Attachments in EDI-INT..........................3 
      2.1 Multipart/Related Structure................................3 
      2.2 EDIINT Features Header.....................................3 
      2.3 MIC Calculation............................................4 
      2.4 Document Processing........................................5 
      2.5 Content-Types to Support...................................5 
   3. Example Message................................................5 
   4. Security Considerations........................................6 
   5. References.....................................................7 
      5.1 Normative References.......................................7 
 
 
Meadors                 Expires - December 2008               [Page 2] 
Draft               Multiple Attachments for EDIINT          June 2008 
 
 
      5.2 Informative References.....................................7 
   Author's Address..................................................7 
    
    
1. 
   Introduction 
    
   The primary work of EDI-INT was to develop a secure means of 
   transporting EDI documents over the Internet. This was described in 
   the three working group developed standards for secure transport over 
   SMTP [AS1], HTTP [AS2] and FTP [AS3].  For most uses of EDI, all 
   relevant information to complete a single business transaction could 
   be stored in a single document. As adoption of EDI-INT grew, new 
   industries and businesses began using AS2 and needing to include 
   multiple documents in a single message to complete a trading partner 
   transaction. These documents were a variety of MIME media types. 
    
   This informational draft describes how to use the MIME 
   multipart/related envelope structure within EDI-INT messages to store 
   multiple document attachments. Details of computing the MIC value 
   over this envelope is covered. A minimum listing of MIME media types 
   to support within the multipart/related envelope is given along with 
   information on extracting these documents. 
    
2. 
  Using Multiple-Attachments in EDI-INT 
    
2.1 
   Multipart/Related Structure 
    
   Multiple payload attachments for EDI-INT messages are stored within a 
   multipart/related MIME envelope [RFC2387]. The multipart/related 
   structure allows an unlimited number of attachments, but the 
   attachments MUST be inter-related to complete a transaction. Multiple 
   attachments in EDI-INT MUST NOT be used for batch processing of EDI 
   or other documents which are not inter-related. For example numerous 
   EDI purchase orders for different products must not be sent in a 
   multipart/related envelope but instead be transmitted in separate, 
   individual EDI-INT messages. 
    
   The attached payloads can be of any MIME content-type depending on 
   the trading partner agreement, but section 2.4 lists the content-
   types which MUST be supported. The use and format of the 
   multipart/related envelope follows the rules in RFC 2387, including 
   the required type parameter to determine the root body part. The use 
   of the optional start parameter is recommended. 
    
    
2.2 
   EDIINT Features Header 
    
   To indicate support for MA, an EDIINT application MUST use the EDIINT 
   Features header [EDIINT-FEATURE]. The Feature Header indicates the 
 
 
Meadors                 Expires - December 2008               [Page 3] 
Draft               Multiple Attachments for EDIINT          June 2008 
 
 
   instance application can support various features, such as 
   certification exchange. The header is present in all messages from 
   the instance application, not just those which feature certification 
   exchange. 
    
   For applications implementing certification exchange, the MA-Feature-
   Name MUST be used within the EDIINT Features header: 
    
      MA-Feature-Name = "multiple-attachments" 
    
   An example of the EDIINT Features header in a message from an 
   application supporting MA: 
    
      EDIINT-Features: multiple-attachments 
    
    
2.3 
   MIC Calculation 
    
   MIC calculation in an EDI-INT message with multiple attachments is 
   performed in a similar fashion to a single EDI payload. Section 5.2.1 
   of [AS1] and section 2 of [EDIINT COMPRESSION] describe the MIC 
   calculations used for single document attachments. 
    
   When a digital signature is applied to the multipart/related 
   envelope, the MIC is calculated on the entire multipart/related 
   envelope, including the MIME header and all attached documents. If 
   compression is first applied to the envelope and the digital 
   signature is then applied to the compressed data, the MIC is 
   calculated over the compressed envelope including the MIME headers. 
    
   For a compressed but unsigned message, regardless of encryption, the 
   MIC is calculated over the uncompressed multipart/related envelope 
   including any applied Content-Transfer-Encoding. The envelope MUST be 
   canonicalized before the MIC is calculated. 
    
   For an encrypted but unsigned and uncompressed message, the MIC is 
   calculated on the decrypted multipart/related envelope, including 
   header and all attached documents. The envelope MUST be canonicalized 
   before the MIC is calculated. 
    
   For an unsigned and unencrypted message, the MIC is calculated over 
   the data inside the multipart/related boundaries prior to Content-
   Transfer-Encoding. However, unsigned and unencrypted messages SHOULD 
   not be sent due to lack of security. 
    
   If the expected MIC value differs from the calculated MIC value, all 
   attachments MUST be considered invalid and retransmitted. 
    

 
 
Meadors                 Expires - December 2008               [Page 4] 
Draft               Multiple Attachments for EDIINT          June 2008 
 
 
2.4 
   Document Processing 
    
   Upon receipt of an EDI-INT message with multiple attachments, the 
   receiving user agent MUST be able to extract the attached payloads 
   from the message rather than only removing the multipart/related 
   envelope from the message. The storing or processing of the documents 
   as they relate to the pending transaction is implementation 
   dependent.  
    
2.5 
   Content-Types to Support 
    
   Documents of the following MIME media types MAY be found in a 
   multipart/related envelop and MUST be accepted by the user agent. 
   Other media types MAY be accepted depending upon trading partner 
   agreement. 
    
   application/xml 
   application/pdf 
   application/msword 
   application/vnd.ms-excel, application/x-msexcel 
   application/rtf 
   application/octet-string  
   application/zip 
   image/bmp 
   image/gif 
   image/tiff 
   image/jpeg 
   text/plain 
   text/html 
   text/rtf 
   text/xml 
    
3. 
  Example Message 
    
   Here is an example AS2 message which uses two attachments. The first 
   attachment is an XML document which is the root attachment, and the 
   second attachment is a PDF document. For both the XML and PDF 
   documents as well as the applied digital signature, their content has 
   been omitted for size consideration. This example is provided as an 
   illustration only and is not considered part of the specification. If 
   the example conflicts with the definitions specified above or in the 
   other referenced RFCs, the example is considered invalid. 
    
    
   POST /as2 HTTP/1.1 
   Host: www.example.com:8080 
   Connection: Close, TE 
   Message-ID: <1109712943488@10.65.122.242> 
   Subject: Multiple Attachment Example 
 
 
Meadors                 Expires - December 2008               [Page 5] 
Draft               Multiple Attachments for EDIINT          June 2008 
 
 
   Date: Tue, 01 Mar 2005 21:37:03 GMT 
   AS2-To: TradingPartner 
   AS2-From: User 
   AS2-Version: 1.2 
   EDIINT-Features: multiple-attachments 
   Disposition-Notification-To: http://www.example.com/as2 
   Disposition-Notification-Options: 
      signed-receipt-protocol=optional,pkcs7-signature; 
      signed-receipt-micalg=optional,sha1 
   Content-type: multipart/signed; 
      protocol="application/pkcs7-signature"; micalg=sha1; 
      boundary="OUTER-BOUNDARY" 
   Content-length: 207440 
    
   --OUTER-BOUNDARY  
   Content-Type: Multipart/Related; boundary=" INNER-BOUNDARY"; 
      start="<root.attachment>"; type="application/xml" 
    
   --INNER-BOUNDARY 
   Content-Type: application/xml 
   Content-ID: <root.attachment> 
    
   [XML DOCUMENT] 
    
   --INNER-BOUNDARY 
   Content-Type: application/pdf 
   Content-ID: <2nd.attachment> 
    
   [PDF DOCUMENT] 
    
   --INNER-BOUNDARY-- 
    
   --OUTER-BOUNDARY 
   Content-Type: application/pkcs7-signature 
    
   [DIGITAL SIGNATURE] 
    
   --OUTER-BOUNDARY-- 
    
    
4. 
  Security Considerations 
    
   Multiple attachments have very similar security concerns to what is 
   described in the three EDI-INT transport standards. Please refer to 
   these standards for their security considerations. The only 
   additional security consideration is that if the MIC calculation by 
   user agent differs from expected MIC calculation, all the attached 
   documents MUST be considered invalid. Because the MIC calculation is 

 
 
Meadors                 Expires - December 2008               [Page 6] 
Draft               Multiple Attachments for EDIINT          June 2008 
 
 
   over the multipart/related envelop, the MIC validates the content-
   integrity of all the documents. 
    
    
5. 
  References 
5.1 
    Normative References 
    
   [AS1] RFC3335 "MIME-based Secure Peer-to-Peer Business Data 
      Interchange over the Internet using SMTP", T. Harding, R. 
      Drummond, C. Shih, 2002. 
    
   [AS2] RFC4130 "MIME-based Secure Peer-to-Peer Business Data 
      Interchange over the Internet using HTTP", D. Moberg, R. 
      Drummond, 2005. 
    
   [AS3] RFC 4823 "FTP Transport for Secure Peer-to-Peer", T. Harding, 
      R. Scott, 2007. 
    
   [EDIINT COMPRESSION] draft-ietf-compression-10.txt "Compressed Data 
      for EDIINT", T. Harding, 2008. 
    
   [EDIINT-FEATURE] draft-meadors-ediint-feature-header-04.txt "Feature 
      Header for EDI-INT", K. Meadors, 2008. 
            
   [RFC2119] RFC2119 "Key Words for Use in RFC's to Indicate Requirement 
      Levels", S.Bradner, March 1997. 
    
   [RFC2387] RFC2387 "The MIME Multipart/Related Content-type", E. 
      Levinson, August 1998. 
    
    
5.2 
   Informative References 
    
    
Author's Address 
    
   Kyle Meadors 
   Drummond Group Inc. 
   #238 13359 North Highway 183 
   Austin, TX  78750 USA 
   Email: kyle@drummondgroup.com 
    
    
Full Copyright Statement 
    
   Copyright (C) The IETF Trust (2008). 
 


 
 
Meadors                 Expires - December 2008               [Page 7] 
Draft               Multiple Attachments for EDIINT          June 2008 
 
 
   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. 
    
   "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." 
 
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. 
    
   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. 
    
   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. 
 
 











 
 
Meadors                 Expires - December 2008               [Page 8]