(RFC 1767 published March 1995, subtype last updated March 1995)

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