RE: EDI over http?

[Rik Drummond <drummond@xxxxxxxxxx>]

This sounds like the Actra protocol proposal (large paper) late last year. It was a combination of nntp and smtp.... for both sending and receiving information in the same session.

Later, Rik

-----Original Message-----
From:	Matthew James Gering [SMTP:mgering@xxxxxxxxxxxx]
Sent:	Tuesday, June 24, 1997 1:54 AM
To:	'ietf-ediint@xxxxxxx'
Subject:	Re: EDI over http?


Indeed, a http server is not by default also an http client, but it is
trivial to make one so -- all proxy servers are both http clients and
servers. But the point is irrelavent, http, smtp, ftp and other internet
protocol client libraries are widely available and trivial to implement.

I think "real time SMTP" or psuedo-realtime -- something that at least
handles fowarding and queuing, would be the best.

Although I entirely agree that a simple open internet-based protocol should
be used for for EDI for interoperability and low implementation cost, I
don't think an appropriate protocol exists.

Personally I'd like to see the inclusion of some transaction-related
functions such as are included in more advanced computer-to-computer
messaging systems such as Microsoft's MSMQ/MTS, IBM's MVS/CICS and
MQSeries, etc. But perhaps this just shows my limited understanding of the
EDI process itself.

	Matt

----------
> No I don't think you are missing anything here. My point was that
> whether we adopt a "real time SMTP" as Carl Hage suggested, or use HTTP
> POST over SSL, some amount of server side implementation is required. I
> thought some of the discussion was assuming that you get HTTP over SSL
> for "free", when you use a web server.
>