In the mid-Eighties, powerful forces made the EDI marketplace converge around relatively few standards; nowadays, most EDI applications speak ANSI ASC 12 or UN/EDIFACT; the latter one refers to ISO 9735 for its definition.
EDI messages according to these standards are text-like in nature; they use delimiting characters, not structures like ASN.1, but also binary; they use control characters, not linebreaks and whitespace formatting.
Lots of EDI info is available on the Net; the DISA reference pagesare just a few among many.
This was done by defining a new content type - P.35 or P.edi. This means that a standard (P2) user agent can not view the EDI message; this fits well with the trading model of having EDIFACT messages go only between EDI applications.
Users are identified by their EDI identifiers, carried inside the EDI transaction; the mapping between these and the corresponding X.400 address is outside the scope of the standard.
Some of the parameters of the EDI transaction may optionally be copied to the "header" of the message for easier access, but the EDI transaction is delivered complete in the EDI format, not an X.400 format.
Some notifications are defined for "taking responsibility" or "refusing responsibility" for an EDI transaction.
The X.400 EDI is available from several EDI vendors today.
This defines body parts for EDI, which means that it is possible for a normal user agent to add a "viewer" for these kinds of objects, and use the same user agent for ordinary mail and EDI transactions.
No parameters are called out from the EDI message, and no format changes are applied to the EDI message, except the transfer coding required for the message to be safe in the mail network.
A Frequently Asked Questions list (draft-ietf-edi-faq-00.txt) is in preparation, and is expected to be published as an RFC shortly.
No notifications have been called out in the MIME work; the EDI-format notification transactions may be used.
At the moment, no implementations are known to use the MIME EDI format, but most people looking at it think that it is trivial to add this to existing EDI machinery, given that a MIME UA is available.