Multiple Attachments for Electronic Data Interchange - Internet Integration (EDIINT)
RFC 6362

Approval announcement
Draft of message to be sent after approval:

From: The IESG <>
To: IETF-Announce <>
Cc: RFC Editor <>
Subject: Document Action: 'Multiple Attachments for EDI-INT' to Informational RFC (draft-meadors-multiple-attachments-ediint-14.txt)

The IESG has approved the following document:
- 'Multiple Attachments for EDI-INT'
  (draft-meadors-multiple-attachments-ediint-14.txt) as an Informational

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Pete Resnick.

A URL of this Internet Draft is:

Technical Summary

   The EDI-INT AS1, AS2 and AS3 messages 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
   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

Working Group Summary

   This is not a WG document. It was originally submitted as an Independent Submission
   to RFC Editor, but after a discussion between the author, sponsoring AD and ISE it was
   decided that it is suitable for the IETF stream.

Document Quality

   There are at least 8 different implementations of this extension.


   Pete Resnick is the Responsible Area Director.

RFC Editor Note

In Section 2.5, please add to the end of the 1st paragraph:

Existing text:
   Documents of the following MIME media types MAY be found in a
   multipart/related envelope and MUST be accepted by the user agent.
   However, any media type can be used depending upon industry need, and
   other media types MAY be accepted depending upon trading partner

  Please see [MIMEREG] for the definitions of the Media Types listed below.

In Section 2.5 delete:

      application/, application/x-msexcel


In Section 3, in the example:

         protocol="application/pkcs7-signature"; micalg=sha1;

         protocol="application/pkcs7-signature"; micalg=sha-1;

Add the following reference to the list of Normative References: