MIME Encapsulation of EDI Objects
draft-ietf-edi-mime-01

Network Working Group                                 D. Crocker
Internet-Draft:  DRAFT-IETF-EDI-MIME-01.{txt,ps}      Brandenburg Consulting
Expiration <6/95>

                MIME Encapsulation of EDI Objects

STATUS OF THIS MEMO

This document is an Internet-Draft.  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.''

To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).

TABLE OF CONTENTS

1. Introduction
2. Application/EDIFACT specification
3. Application/EDI-X12 specification
4. Application/EDI-Consent specification
5. Sample edi usage in MIME-based email
6. References
7. Security considerations
8. Acknowledgments
9. Contact
10. Appendix - MIME for EDI users

D. Crocker                                                               1

Internet Draft            EDI in MIME          (Expiration: 6/95)

Introduction

Electronic Data Interchange (EDI) provides a means of conducting
structured transactions between trading partners.  The delivery
mechanism for these types of transactions in a paper world has
been the postal system, so it is to be expected that electronic
mail would serve as a natural delivery mechanism for electronic
transactions.  This specification permits formatted electronic
business interchanges to be encapsulated within MIME messages
[Bore92].  For the specification effort, the basic building block
from EDI is an interchange.

This specification pertains only to the encapsulation of EDI
objects within the MIME environment.  It intends no changes in
those objects from the primary specifications that define the
syntax and semantics of them.  EDI transactions take place
through a variety of carriage and exchange mechanisms.  This
specification adds to that repertoire, by permitting convenient
carriage through Internet email.

Since there are many different EDI specifications, the current
document defines three distinct categories as three different
MIME content-types.  One is Application/EDI-X12, indicating that
the contents conform to the range of specifications developed
through the X12 standards organization [X125, X126, X12V].
Another is Application/EDIFACT, indicating that the contents
conform to the range of specifications developed by the United
Nations Working Party 4 Group of Experts 1 EDIFACT boards [FACT,
FACV].  The last category covers all other specifications; it is
Application/EDI-consent.

2.     APPLICATION/EDIFACT SPECIFICATION

The Application/EDIFACT MIME body-part contains data as specified
for electronic data interchange by [FACT, FACV].

D. Crocker                                                            2

Internet Draft            EDI in MIME          (Expiration: 6/95)

Within EDIFACT, information is specified by:

MIME type name:               Application

MIME subtype name:            EDIFACT

Required parameters:          none

Optional parameters:          CHARSET, as defined for MIME

Encoding considerations:      May need BASE64 or QUOTED-PRINTABLE
                              transfer encoding

Security considerations:      See separate section in the
                              document.

Published specification:      Contained in the following section.

Rationale:                    The EDIFACT specifications are
                              accepted standards for a class of
                              inter-organization transactions;
                              this permits their transmission
                              over the Internet, via email.

Contact-info:                 See Contact section, below.

Detail specific to MIME-based usage:

     This is a generic mechanism for sending any EDIFACT
     interchange.  The object is self-defining, in terms of
     indicating which specific EDI objects are included.  Most
     EDI data is textual, but special characters such as some
     delimiters may be non-printable ASCII or some data may be

D. Crocker                                                            3

Internet Draft            EDI in MIME          (Expiration: 6/95)

     pure binary.  For EDI objects containing such data, the MIME
     transfer mechanism may need to encode the object in Content-
     Transfer-Encoding:quoted-printable or base64.

3.     APPLICATION/EDI-X12 SPECIFICATION

The Application/EDI-X12 MIME body-part contains data as specified
for electronic data interchange by  [X125, X12.6, EDIV].

Within MIME, EDI-X12 information is specified by:

MIME type name:               Application

MIME subtype name:            EDI-X12

Required parameters:          none

Optional parameters:          CHARSET, as defined for MIME

Encoding considerations:      May need BASE64 or QUOTED-PRINTABLE
                              transfer encoding

Security considerations:      See separate section in the
                              document.

Published specification:      Contained in the following section.

Rationale:                    The ASC X12 EDI specifications are
                              accepted standards for a class of
                              inter-organization transactions;
                              this permits their transmission
                              over the Internet, via email.

Contact-info:                 See Contact section, below.

D. Crocker                                                              4

Internet Draft            EDI in MIME          (Expiration: 6/95)

Detail specific to MIME-based usage:

     This is a generic mechanism for sending any ASC X12
     interchange.  The object is self-defining, in terms of
     indicating which specific EDI objects are included.  Most
     EDI data is textual, but special characters such as some
     delimiters may be non-printable ASCII or some data may be
     pure binary.  For EDI objects containing such data, the MIME
     transfer mechanism may need to encode the object in Content-
     Transfer-Encoding:quoted-printable or base64.

4.     APPLICATION/EDI-CONSENT SPECIFICATION

The Application/EDI-consent MIME body-part contains data as
specified for electronic data interchange with the consent of
explicit, bilateral trading partner agreement exchanging the EDI-
consent traffic.  As such, use of EDI-consent only provides a
standard mechanism for "wrapping" the EDI objects but does not
specify any of the details about those objects.

Within MIME, EDI-consent information is specified by:

MIME type name:               Application

MIME subtype name:            EDI-consent

Required parameters:          none

Optional parameters:          CHARSET, as defined for MIME

Encoding considerations:      May need BASE64 or QUOTED-PRINTABLE
                              transfer encoding

Security considerations:      See separate section in the
                              document.

D. Crocker                                                             5

Internet Draft            EDI in MIME          (Expiration: 6/95)

Published specification:      Contained in the following section.

Rationale:                    Existing practice for exchanging
                              EDI includes a very wide range of
                              specifications which are not part
                              of the usual, accredited standards
                              world.  Nevertheless, this traffic
                              is substantial and well-
                              established.  This content type
                              provides a means of delimiting such
                              content in a standard fashion.

Contact-info:                 See Contact section, below.

Detail specific to MIME-based usage:

     This is a generic mechanism for sending any EDI object
     explicitly agreed to by the trading partners.  X12 and
     EDIFACT object must be sent using their assigned MIME
     content type.  EDI-consent is for all other EDI objects, but
     only according to trading partner agreements between the
     originator and the recipient.   Most EDI data is textual,
     but special characters such as some delimiters may be non-
     printable ASCII or some data may be pure binary.  For EDI
     objects containing such data, the MIME transfer mechanism
     may need to encode the object in Content-Transfer-
     Encoding:quoted-printable or base64.

5.     SAMPLE EDI USAGE IN MIME-BASED EMAIL

Actual use of EDI within MIME-based mechanisms requires attention
to considerable detail.  This section is intended as an example
of the gist of the formatting required to encapsulate EDI objects

D. Crocker                                                          6

Internet Draft            EDI in MIME          (Expiration: 6/95)

within Internet mail, using MIME.  To send a single EDIFACT
interchange:

To:  <<recipient organization EDI email address>>
Subject:
From: <<sending organization EDI email address>>
Date:
Mime-Version: 1.0
Content-Type: Application/EDIFACT
Content-Transfer-Encoding:  QUOTED-PRINTABLE

<<standard EDIFACT Interchange goes here>>

6.     REFERENCES

[Bore92]    Borenstein, N. & Freed, N., "Mime (Multipurpose
            Internet Mail Extensions):  Mechanisms for
            Specifying and Describing The Format of Internet
            Message Bodies".  March, 1992, Network Information
            Center, RFC 1341.

[Brad89]    Braden, R.T., "Requirements for Internet hosts -
            application and support".  October, 1989, Network
            Information Center, RFC 1321.

[Croc82]    Crocker, D.,  "Standard for the Format of Internet
            Text Messages".  September, 1982, Network
            Information Center, RFC 822.

[Rose93]    Rose, M., "The Internet Message:  Closing the Book
            with Electronic Mail".  PTR Prentice Hall, Englewood
            Cliffs, N.J.  (1993)

[Post82]    Postel, J.,  "Simple Mail Transfer Protocol".
            October, 1982, Network Information Center, RFC 821.

D. Crocker                                                               7

Internet Draft            EDI in MIME          (Expiration: 6/95)

[X12V]      Data Interchange Standards Association; sets of
            specific EDI standards are ordered by their version
            number; Washington D.C.

[X125]      ANSI X12.5 Interchange Control Structure for
            Electronic Data Interchange, Washington D.C.: DISA

[X126]      ANSI X12.6 Applications Control Structures for
            Electronic Data Interchange, Washington D.C.: DISA

[FACT]      United Nations Economic Commission (UN/EC)
            Electronic Data Interchange For Administration,
            Commerce and Transport (EDIFACT) - Application Level
            Syntax Rules (ISO 9735), 1991.

[FACV]      Version sets contains the specific syntax documents,
            the element and segment dictionaries, and the
            transaction/message specifications.

7.     SECURITY CONSIDERATIONS

EDI transactions typically include sensitive data, so that
transmission often needs to attend to authentication, data
integrity, privacy, access control and non-repudiation concerns.
This specification permits transmission of such sensitive data
via Internet mail and other services which support MIME object
encapsulation.  For transmission of sensitive data, it is
essential that appropriate security services, such as
authentication, privacy and/or non-repudiation be provided.

This specification does NOT, itself, provide any security-related
mechanisms.  As needed and appropriate, such mechanisms MUST be
added, either via Internet MIME-based security services or any

D. Crocker                                                               8

Internet Draft            EDI in MIME          (Expiration: 6/95)

other services which are appropriate to the user requirements,
such as those provided by EDI-based standards.

8.     ACKNOWLEDGMENTS

Tom Jones offered introductory text and descriptions of candidate
header options.  Numerous working group participants provided
review and comment, especially Walt Houser, Gail Jackson, and Jim
Amster.

9.     CONTACT

David H. Crocker

Brandenburg Consulting
675 Spruce Dr.
Sunnyvale, CA 94086 USA

<dcrocker@mordor.stanford.edu>

Phone:  +1 408 246 8253
Fax:  +1 408 249 6205

10.    APPENDIX - MIME FOR EDI USERS

To assist those familiar with EDI but not with Internet
electronic mail, this Appendix is provided as a very brief
introduction, primarily to give pointers to the relevant
specifications.  This section is in no way intended to be a
thorough introduction.  An excellent introductory text is
[Rose93].

D. Crocker                                                               9

Internet Draft            EDI in MIME          (Expiration: 6/95)

Internet electronic mail follows the classic user agent/mail
transfer agent model.  In this model, user software produces a
standardized object which is transferred via standard exchange
protocols.

An Internet electronic mail object comprises a collection of
headers, followed by a (possibly structured) body.  The headers
specify such information as author and recipient addresses,
subject summary, creation date, handling node names, and so on,
and are defined by RFC822 and RFC1123 [Croc82, Brad89].  If the
body is structured, it conforms to the rules of the Multipurpose
Internet Message Exchange (MIME) [Bore92].  A structured body may
have parts encoded in different text character sets, or even of
entirely different types of data, such as voice or graphics.

The Simple Mail Transfer Protocol (SMTP) [Post82, Brad89]
performs the primary task of message transmission.  User posting
and delivery interactions, between the user agent and the message
transfer agent, on the same machine, are not standardized and are
platform-specific.

An EDI-related use of Internet Mime email will have (at least)
the following components:

       Business Program/Data base -> EDI Translator ->
       -> MIME encapsulation -> RFC822 packaging -> mail
       submission ->
       -> SMTP relaying ->
       -> mail delivery -> RFC822 & Mime stripping ->
       -> EDI Translator -> Business processing

The first and last lines show components normal to all EDI
activities, so that it is only the EDI "transmission" components
that are replaced with Internet modules.

D. Crocker                                                              10

--------------------
Dave Crocker
Brandenburg Consulting                                  +1 408 246 8253
675 Spruce Dr.                                    fax:  +1 408 249 6205
Sunnyvale, CA  94086                       dcrocker@mordor.stanford.edu