As per Relevance of the word electronic, we have this rfc below:
Network Working Group D.
Request for Comments: 1767 Brandenburg
Category: Standards Track March 1995
MIME Encapsulation of EDI
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Table of
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.
Electronic Data Interchange (EDI) provides a means of
structured transactions between trading partners. The
mechanism for these types of transactions in a paper world has
the postal system, so it is to be expected that electronic mail
serve as a natural delivery mechanism for electronic transactions
This specification permits formatted electronic business
to be encapsulated within MIME messages [Bore92]. For
specification effort, the basic building block from EDI is
interchange
This specification pertains only to the encapsulation of EDI
within the MIME environment. It intends no changes in those
from the primary specifications that define the syntax and
of them. EDI transactions take place through a variety of
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
document defines three distinct categories as three different
content-types. One is Application/EDI-X12, indicating that
contents conform to the range of specifications developed through
X12 standards organization [X125, X126, X12V]. Another
Application/EDIFACT, indicating that the contents conform to
range of specifications developed by the United Nations Working
4 Group of Experts 1 EDIFACT boards [FACT, FACV]. The last
covers all other specifications; it is Application/EDI-consent
2. APPLICATION/EDIFACT
The Application/EDIFACT MIME body-part contains data as specified
electronic data interchange by [FACT, FACV].
Within EDIFACT, information is specified by
MIME type name:
MIME subtype name:
Required parameters:
Optional parameters: CHARSET, as defined for
Encoding considerations: May need BASE64 or QUOTED-
transfer
Security considerations: See separate section in
document
Published specification: Contained in the following section
Rationale: The EDIFACT specifications
accepted standards for a class
inter-organization transactions
this permits their
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
interchange. The object is self-defining, in terms
indicating which specific EDI objects are included.
EDI data is textual, but special characters such as
delimiters may be non-printable ASCII or some data may
Crocker [Page 2]
RFC 1767 EDI in MIME March 1995
pure binary. For EDI objects containing such data, the
transfer mechanism may need to encode the object in Content
Transfer-Encoding:quoted-printable or base64.
3. APPLICATION/EDI-X12
The Application/EDI-X12 MIME body-part contains data as specified
electronic data interchange by [X125, X12.6, EDIV].
Within MIME, EDI-X12 information is specified by
MIME type name:
MIME subtype name: EDI-X12
Required parameters:
Optional parameters: CHARSET, as defined for
Encoding considerations: May need BASE64 or QUOTED-
transfer
Security considerations: See separate section in
document
Published specification: Contained in the following section
Rationale: The ASC X12 EDI specifications
accepted standards for a class
inter-organization transactions
this permits their
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
indicating which specific EDI objects are included.
EDI data is textual, but special characters such as
delimiters may be non-printable ASCII or some data may
pure binary. For EDI objects containing such data, the
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
The Application/EDI-consent MIME body-part contains data as
for electronic data interchange with the consent of explicit
bilateral trading partner agreement exchanging the EDI-
traffic. As such, use of EDI-consent only provides a
mechanism for "wrapping" the EDI objects but does not specify any
the details about those objects
Within MIME, EDI-consent information is specified by
MIME type name:
MIME subtype name: EDI-
Required parameters:
Optional parameters: CHARSET, as defined for
Encoding considerations: May need BASE64 or QUOTED-
transfer
Security considerations: See separate section in
document
Published specification: Contained in the following section
Rationale: Existing practice for
EDI includes a very wide range
specifications which are not
of the usual, accredited
world. Nevertheless, this
is substantial and well
established. This content
provides a means of delimiting
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
explicitly agreed to by the trading partners. X12
EDIFACT object must be sent using their assigned
content type. EDI-consent is for all other EDI objects,
only according to trading partner agreements between
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
objects containing such data, the MIME transfer
may need to encode the object in Content-Transfer
Encoding:quoted-printable or base64.
5. SAMPLE EDI USAGE IN MIME-BASED
Actual use of EDI within MIME-based mechanisms requires attention
considerable detail. This section is intended as an example of
gist of the formatting required to encapsulate EDI objects
Internet mail, using MIME. To send a single EDIFACT interchange
To: <<recipient organization EDI email address>>
Subject
From: <organization EDI email address>>
Date
Mime-Version: 1.0
Content-Type: Application/
Content-Transfer-Encoding: QUOTED-
<<standard EDIFACT Interchange goes here>>
6.
[Bore92] Borenstein, N., and N. Freed, "MIME (
Internet Mail Extensions) Part One: Mechanisms
Specifying and Describing the Format of Internet
Bodies", RFC 1521, Bellcore, Innosoft, September 1993.
[Brad89] Braden, R., Editor, "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123,
Engineering Task Force, October 1989.
[Croc82] Crocker, D., "Standard for the Format of
Text Messages", STD 11, RFC 822, UDEL, August 1982.
[Rose93] Rose, M., "The Internet Message: Closing the
with Electronic Mail", PTR Prentice Hall,
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
specific EDI standards are ordered by their
number; Washington D.C
Crocker [Page 5]
RFC 1767 EDI in MIME March 1995
[X125] ANSI X12.5 Interchange Control Structure
Electronic Data Interchange, Washington D.C.:
[X126] ANSI X12.6 Applications Control Structures
Electronic Data Interchange, Washington D.C.:
[FACT] United Nations Economic Commission (UN/EC
Electronic Data Interchange For Administration
Commerce and Transport (EDIFACT) - Application
Syntax Rules (ISO 9735), 1991.
[FACV] Version sets contains the specific syntax documents
the element and segment dictionaries, and
transaction/message specifications
7. SECURITY
EDI transactions typically include sensitive data, so
transmission often needs to attend to authentication, data integrity
privacy, access control and non-repudiation concerns.
specification permits transmission of such sensitive data
Internet mail and other services which support MIME
encapsulation. For transmission of sensitive data, it is
that appropriate security services, such as authentication,
and/or non-repudiation be provided
This specification does NOT, itself, provide any security-
mechanisms. As needed and appropriate, such mechanisms MUST
added, either via Internet MIME-based security services or any
services which are appropriate to the user requirements, such
those provided by EDI-based standards
8.
Tom Jones offered introductory text and descriptions of
header options. Numerous working group participants provided
and comment, especially Walt Houser, Gail Jackson, and Jim Amster
9. AUTHOR'S
David H.
Brandenburg
675 Spruce Dr
Sunnyvale, CA 94086
Phone: +1 408 246 8253
Fax: +1 408 249 6205
EMail: dcrocker@mordor.stanford.
Crocker [Page 6]
RFC 1767 EDI in MIME March 1995
10. APPENDIX - MIME FOR EDI
To assist those familiar with EDI but not with Internet
mail, this Appendix is provided as a very brief introduction
primarily to give pointers to the relevant specifications.
section is in no way intended to be a thorough introduction.
excellent introductory text is [Rose93].
Internet electronic mail follows the classic user agent/mail
agent model. In this model, user software produces a
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
information as author and recipient addresses, subject summary
creation date, handling node names, and so on, and are defined
RFC822 and RFC1123 [Croc82, Brad89]. If the body is structured,
conforms to the rules of the Multipurpose Internet Message
(MIME) [Bore92]. A structured body may have parts encoded
different text character sets, or even of entirely different types
data, such as voice or graphics
The Simple Mail Transfer Protocol (SMTP) [Post82, Brad89]
the primary task of message transmission. User posting and
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)
following components
Business Program/Data base -> EDI Translator ->
-> MIME encapsulation -> RFC822 packaging ->
submission ->
-> SMTP relaying ->
-> mail delivery -> RFC822 & Mime stripping ->
-> EDI Translator -> Business
The first and last lines show components normal to all EDI activities
so that it is only the EDI "transmission" components that are
with Internet modules
Crocker [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
