Re: EDI Support in MIME
"Ned Freed, Postmaster" <NED@hmcvax.claremont.edu> Tue, 12 May 1992 19:34 UTC
Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa25042; 12 May 92 15:34 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa28932; 12 May 92 15:40 EDT
Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa28910; 12 May 92 15:40 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA06414; Tue, 12 May 92 15:09:38 EDT
Received: from CBROWN.CLAREMONT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA06410; Tue, 12 May 92 15:09:32 EDT
Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01GJX9AN6E6SAKTIVK@HMCVAX.CLAREMONT.EDU>; Tue, 12 May 1992 12:09 PST
Date: Tue, 12 May 1992 12:09:00 -0800
From: "Ned Freed, Postmaster" <NED@hmcvax.claremont.edu>
Subject: Re: EDI Support in MIME
To: anderson@tramp.colorado.edu
Cc: ietf-822@dimacs.rutgers.edu
Message-Id: <01GJX9AN6E6SAKTIVK@HMCVAX.CLAREMONT.EDU>
X-Vms-To: IN%"anderson@tramp.colorado.edu"
X-Vms-Cc: IN%"ietf-822@dimacs.rutgers.edu"
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
- Re: EDI Support in MIME John C Klensin
- Re: EDI Support in MIME ANDERSON PAMELA DANIEL
- Re: EDI Support in MIME Ned Freed, Postmaster
- Re: EDI Support in MIME ANDERSON PAMELA DANIEL