GB/Z 18812-2002MIME encapsulation of EDI objects (English PDF)

Introduction

Electronic data interchange (EDI) provides a means of transmitting structured data between trading partners, but its traditional value-added network transmission mechanism has hindered the spread and application of EDI. The Internet, with its advantages of reliability, low cost, broadband support and easy access, has opened a new route for the transmission of EDI, and using the mail transmission system of the Internet to transmit EDI objects is the most convenient and workable method.

To regulate further the transmission of EDI objects over the Internet, the IETF has drawn up a series of RFCs, covering everything from how to encapsulate an EDI object to how to achieve secure transmission; this is a comparatively complete set of solutions for transmitting EDI by electronic mail over the Internet, and RFC 1767 is one of them.

1 Scope

This guiding technical document specifies the format for encapsulating EDI objects in the Multipurpose Internet Mail Extensions (MIME) protocol. Unless stated otherwise, an EDI object in this guiding technical document means a complete EDI interchange including the interchange header and the interchange trailer.

This guiding technical document specifies only the encapsulation of the EDI object in a MIME environment and does not deal with the syntax and semantics inside the object. EDI transactions are carried out through a series of different transmission and interchange mechanisms; this guiding technical document adds one further option through the convenient Internet electronic mail transmission mechanism.

This guiding technical document applies to every situation in which EDI objects are transmitted by electronic mail.

2 Normative references

The provisions in the following documents become provisions of this guiding technical document through reference in it. For dated references, subsequent amendments (excluding corrections) or revisions do not apply to this guiding technical document; however, parties reaching agreement on the basis of this guiding technical document are encouraged to study whether the latest editions of those documents may be used. For undated references, the latest edition applies.

RFC 2045, Multipurpose Internet Mail Extensions - Part 1: Format of Internet message bodies

RFC 822, Standard for the format of ARPA Internet text messages

3 Types of EDI interchange

EDI standards exist worldwide in several forms; this guiding technical document divides them into three classes: a) EDIFACT, a set of EDI standards drawn up by the United Nations Economic Commission for Europe (UN/ECE) and widely applied worldwide - the series of EDIFACT national or sector subset standards formed in China by trimming the EDIFACT standard falls within this class; b) ANSI X12, a set of EDI standards drawn up by the American National Standards Institute, used mainly in North America; c) other EDI standards, drawn up by regional organizations or by individual countries and used within a small compass.

4 The relevant header fields in MIME

MIME is a set of Internet-based multipurpose mail extension protocols. This set of Internet protocols extends RFC 822 substantially and adds the definition of the following message formats: text message bodies expressed in character sets other than US-ASCII; non-text message bodies, as an extension set of different formats; message bodies made up of several parts; and text header information expressed in character sets other than US-ASCII.

RFC 822 defines the standard format of text mail on the Internet, but says nothing about multimedia formats; even for text it restricts the user to US-ASCII strings and says nothing about other character sets. The MIME protocol set, without creating any incompatibility, adds a mechanism for transmitting multimedia formats by introducing the relevant header fields. The specific header fields are as follows.

a) The MIME version header field gives a version number declaring which version of MIME the message conforms to, so that the mail handler can tell messages generated by the new and the old version apart. The version number is made up of two digits separated by a decimal point, so that the standard for the message format may be extended in future.

b) The content type header field. The purpose of this field is to describe the data in the message body, so that the receiving agent can present that data to the user by a suitable method or mechanism; the value of the field is called the media type. The content type header field defines the data type in the entity through the media type and the subtype identifier; for certain special media some additional information may have to be given, and that additional information follows the type identifier immediately as a set of parameters, in no particular order.

Generally speaking, the media type states roughly the basic data type and the subtype states the specific format of the data type. A parameter is a modifier of the media subtype, but does not affect the nature of the content in the entity. The setting of the parameter values depends on the media type and subtype, or is optional. Most parameter values relate only to one particular subtype; for example the parameter CHARSET applies to any subtype of the text type, the parameter boundary applies to any subtype of the multipart type, and the parameter MicAlg is used to state the algorithm of the integrity control value.

Media types fall into two broad classes: discrete-type and composite-type. The discrete types are five: text, image, audio, video and application. The composite types are two: message and multipart. These seven media types basically cover all media types; if the user extends them, the token has to be defined beginning with X, so as to avoid conflict with the names of future standards. It is recommended that the user extend only the subtypes; the only syntactic restriction on the definition of a subtype name is that the name must not conflict.

c) The content transfer encoding header field. This field can state both the encoding conversion applied to the message body and the domain of the conversion result. Encoding conversion usually processes the data so that it can pass through a mail transmission system restricted in data or in character set. The IETF at present defines three conversion types: identity (no conversion), quoted-printable and base64. When the value of the content encoding header field is 7bit, 8bit or binary, identity conversion is meant, and these values serve only as indicators. The quoted-printable and base64 encoding conversions convert an arbitrary format into a 7-bit-based data format, so that the data passes safely through certain restricted transmission protocols.

d) The content identification header field and the content description header field. In some more advanced applications it may be desirable to reference other messages; the content identification header field provides that function. Like the unique identification number (ID) of a message, the content identification header field must be unique. The content description header field is used to give descriptive information about the content in the message body.

5 MIME encapsulation of an EDIFACT-based EDI interchange

When an EDI interchange of the EDIFACT type is encapsulated, the relevant information in MIME is defined as follows: MIME type Application; MIME subtype EDIFACT; parameters CHARSET, MicAlg and so on; content transfer encoding header field base64 or quoted-printable; content identification header field defined by the user according to the reference situation; content description header field stated by the user.

The MIME media type is taken as Application: whatever type of EDI interchange is encapsulated, the MIME media type is always Application. When EDI conforming to the EDIFACT standard is encapsulated, the MIME media subtype is defined as EDIFACT. The parameters here are all optional; for example, if the EDI message contains Chinese characters, CHARSET is defined as gb18030. Most EDI data is text, but certain special characters, such as separators, may be non-printing ASCII characters, or certain data may be pure binary; for an EDI object containing such data the content transfer encoding header field has to be defined as base64 or quoted-printable. The content identification header field and the content description header field are both defined by the user according to the particular circumstances.

7 MIME encapsulation of other types of EDI interchange

Here the MIME subtype becomes EDI-consent, and the content of the other header fields is the same as in Clause 5. An example of a MIME-encapsulated EDI interchange of another EDI type is given as: To: editest@cyclonesoftware.com; Subject:; From: ediSender@cyclonesoftware.com; Date: Thu, 3 June 2000 11:30:29; Mime-Version: 1.0; Content-Type: application/EDI-consent; Content-Transfer-Encoding: base64; Content-Description: Invoice Message, followed by the start-of-interchange marker, the EDI interchange and the end-of-interchange marker.

8 The typical process of transmitting an EDI object by electronic mail

The typical steps by which a MIME-encapsulated EDI object is transmitted by electronic mail are shown in Figure 1: the business program or database passes to the EDI translator; then MIME encapsulation, RFC 822 packing and mail submission; then SMTP relay; then mail delivery, RFC 822 and MIME unpacking; and finally the EDI translator and business processing.

9 Security matters

EDI transactions usually contain sensitive data, so that transmission has to take account of authentication, data integrity, confidentiality, access control and non-repudiation. This guiding technical document specifies the manner of transmitting sensitive data by Internet mail and the other services supporting MIME object encapsulation. For sensitive data it is necessary to consider security services such as authentication, confidentiality and non-repudiation. This guiding technical document does not itself provide any security mechanism; where necessary and appropriate, such a mechanism has to be added during transmission, and MIME-based security services or EDI-standard-based security services may be used.

For MIME-based security services see RFC 2630 and RFC 2633, Secure MIME (S/MIME) message specification, and RFC 2015, Security MIME in PGP format; and RFC 1991, PGP message exchange formats, for the security specification of the mail data interchange used for administrative purposes.