Re: EDI over http?

[chucks@xxxxxxxxxxxxx (Chuck Shih)]

Peter,

Since EDI is generally server to server, doesn't adopting a http/SSL
transport also imply that the client side http/SSL implementation be
done on the server side as well? 

For instance, the browser will implement the client side SSL functions
such as server certificate authentication, etc. In the situation where
there is no browser, and a server needs to send the EDI file to another
server, doesn't the sending server need to implement the http/SSL client
side dialogues?

Does this mean that companies would need to go to the expense of
creating a "customised" http/SSL server to support client side
functionality?

Peter Rawlinson wrote:
> 
> Am I right in saying that http is a good, evolved standard anyway and
> that most firewalls will allow message transport via port 80?  This
> being the case, I really don't see why companies should go to the
> expense of creating customised SMTP servers in support of real time
> mail.
> 
> >-----Original Message-----
> >From:  Carl Hage [SMTP:chage@xxxxxxxxx]
> >Sent:  Friday, June 20, 1997 3:35 AM
> >To:    ietf-ediint@xxxxxxx
> >Subject:       RE: EDI over http?
> >
> >
> >
> >On Thu, 19 Jun 1997, Rik Drummond wrote:
> >
> >> This conversation seems to be a good kickoff for our next effort in this
> >>wg.
> >> We so far have the requirements document and the secure smtp based edi
> >document ready to submit to the iesg. Our next effort is real time edi.
> >> The issue is -- bob, Carl and Lincoln have  touched on these in the last
> >few memos -- 1) we need real time edi not smtp and 2) http is not and
> >efficient
> >> means to do this for high activity, large files. What are our options?
> >
> >One think that I think would be good would be to define usage guidelines
> >for real-time smtp based EDI. In other words, use the draft RFC (ASN1)
> >as the basis of the standard, but define requirements for an
> >implementation that would qualify as "real time". What confuses people
> >is that most SMTP implementations are general purpose queuing and
> >store-and-forward implementations. A custom-built SMTP server (e.g.
> >built behind a firewall for EDI use only), could be very efficient and
> >fast, in comparison wo usual smtp/sendmail implementations.
> >
> >This approach would have the advantage of being compatible with
> >any internet email system (incl. gateways).
> >
> >Also, it would be useful to define ways of standardizing usage of
> >message headers (e.g. Subject:) so the off-line retrieve selected
> >message features can be used via the usual POP/IMAP "mailbox"
> >protocols with the ASN1 standard.
> >
> >After "real-time" use of SMTP, a lightweight direct EDI-EDI
> >application messaging protocol could be defined, e.g. simple
> >SSL or secured IP, with X12 or EDIFACT without overhead.
> >
> >