GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1767

Network Working Group D. Crocker Request for Comments: 1767 Brandenburg Consulting Category: Standards Track March 1995

                 MIME Encapsulation of EDI Objects

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Table of Contents

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

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

Crocker [Page 1] RFC 1767 EDI in MIME March 1995

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

Crocker [Page 2] RFC 1767 EDI in MIME March 1995

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

Crocker [Page 3] RFC 1767 EDI in MIME March 1995

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

Crocker [Page 4] RFC 1767 EDI in MIME March 1995

      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 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., and N. Freed, "MIME (Multipurpose
             Internet Mail Extensions) Part One: Mechanisms for
             Specifying and Describing the Format of Internet Message
             Bodies", RFC 1521, Bellcore, Innosoft, September 1993.
 [Brad89]    Braden, R., Editor, "Requirements for Internet Hosts -
             Application and Support", STD 3, RFC 1123, Internet
             Engineering Task Force, October 1989.
 [Croc82]    Crocker, D.,  "Standard for the Format of Internet
             Text Messages", STD 11, RFC 822, UDEL, August 1982.
 [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".
             STD 10, RFC 821, USC/Information Sciences Institute,
             August 1982.
 [X12V]      Data Interchange Standards Association; sets of
             specific EDI standards are ordered by their version
             number; Washington D.C.

Crocker [Page 5] RFC 1767 EDI in MIME March 1995

 [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 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. AUTHOR'S ADDRESS

 David H. Crocker
 Brandenburg Consulting
 675 Spruce Dr.
 Sunnyvale, CA 94086 USA
 Phone:  +1 408 246 8253
 Fax:  +1 408 249 6205
 EMail: dcrocker@mordor.stanford.edu

Crocker [Page 6] RFC 1767 EDI in MIME March 1995

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

Crocker [Page 7]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1767.txt · Last modified: 1995/03/01 21:37 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki