One document matched: draft-crocker-edi-01.txt

Differences from draft-crocker-edi-00.txt

Status of This Memo

This is a preliminary draft document, intended for eventual
submission to the IETF working group process.  At this stage, the
document should be viewed strictly as a think-piece, with
comments, corrections, etc. eagerly sought.


Summary

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. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use
Internet-Drafts as reference material or to cite them other than
as a "working draft" or "work in progress."

IETF Information is available by anonymous FTP from several
Internet sites.  Please check the 1id-abstracts.txt listing to
learn the current status of any Internet Draft.


Table Of Contents
1.   Introduction
2.   APPLICATION/EDI-X12 Content-Subtype Usage in MIME
3.   APPLICATION/EDIFACT Specification
4.   APPLICATION/EDI-Consent Specification
5.   EDI Usage in MIME
6.   References
7.   Security Considerations
8.   Acknowledgments
9.   Contact


1.  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].  The basic building block from EDI is a functional
group of transaction sets, as defined below.  In most cases,
these transaction sets are transmitted in formally packaged EDI
enveloping structures, called interchanges.

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.  Another is
Application/EDIFACT, indicating that the contents conform to the
range of specifications developed by the United Nations
<<edifact>> organization.  The last category covers all other
specifications; it is Application/EDI-consent.


2.  APPLICATION/EDI-X12 Content-Subtype Usage in 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 BINARY 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.

Detail specific to MIME-based usage:
     
     This is a generic mechanism for sending any ASC X12
     transaction set.  The interchange parameter at the beginning
     of the EDI object is used to specify the particular EDI
     transaction set that is included.


3.  APPLICATION/EDIFACT Specification

The APPLICATION/EDIFACT MIME body-part contains data as specified
for electronic data interchange by ASC [EDIX12].

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 BINARY 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
     transaction set.  The interchange parameter at the beginning
     of the EDI object used to specify the particular EDI
     transaction set that is included.


4.  APPLICATION/EDI-Consent Specification

The APPLICATION/EDI-other 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-other only provides a
standard mechanism for "wrapping" the EDI objects but does not
specify any of the details about those objects.

EDI-other 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 BINARY transfer encoding

Security considerations:      See separate section in the
                              document .

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.


5.  EDI Usage in MIME

To send a single bundle of one, or more,  X12-EDI transaction
units:

To:  <<recipient organization EDI email address>>
Subject:
From: <<sending organization EDI email address>>
Date:
Mime-Version: 1.0
Content-Type: APPLICATION/EDI-X12
Content-Transfer-Encoding:  BINARY

<<standard ASC X12 EDI Transaction set 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.

[EDIX12]    ASC X12.5 Interchange Control Structure, and other
            specifications.

[EDIFACT]   "UN/EDIFACT Syntax Rules," ISO 9735, 1991.




7.  Security Considerations

EDI transactions typically include sensitive data, so that
transmission often needs to account for authentication, data
integrity, privacy, access control and non-repudiation concerns.
This specification permits transmission of such sensitive data
via Internet mail.  It does NOT provide any security-related
mechanisms.  As needed and appropriate, such mechanisms MUST be
added to the Internet MIME-based service for this capability to
provide sufficient protection of EDI records.


8.  Acknowledgments

Tom Jones offered introductory text and descriptions of candidate
header options.


9.  Contact

David H. Crocker
Phone:    +1 408 246 8253;      Fax: +1 408 249 6205