There is definitely interest in EDI on the Internet over TCP/IP. It would be
very easy, even trivial, to define a MIME application subtype to handle the
flavor of EDI of your choice. All you need to do is write a very short RFC
defining it.
The problems with EDI arise from its inherent complexity and the plethora
of competing approaches. This has led to a situation where ad-hoc approaches
have been used just as much, if not more, than any standardized approach. By
nonstandard I include cases where some form of EDI is used but not packaged
in a standard way as well as cases where proprietary formats are used and
packaged in whatever manner is appropriate.
I have several customers (some of them very large, one of them is supposedly
a leader in the active deployment of EDI according to the trade rags) who
routinely use existing SMTP/TCP/IP e-mail to send and receive EDI or EDI-like
objects. Amusingly enough, their primary interest in MIME seems to be the
message fragmentation facilities, since the objects they send are sometimes
so huge that the MTBF of some network links is a problem. They don't seem
to care very much about having a standardized way of carrying EDI material
around -- they already have a hack that works quite nicely. (Needless to
say, none of this traffic appears on the Internet. It is all done over
private network links.) I plan to try to interest these folks in adopting
a more standarized approach once EDI objects have been defined for MIME. But
the hook I'll use to catch them will not be interoperability across the
Internet, it will be the ability to use documented facilities in mail software
that are intended to handle MIME message types and subtypes automatically.
In conclusion, I definitely think there is a place for defined EDI types
within the MIME framework, and I would be happy to work with any parties
interested in defining subtypes appropriate for EDI.
Ned