RE: EDI over http?

[Dennis Freeman <DFreeman@xxxxxxxxxxxxx>]

I see that the OBI (Open Buying on the Internet) group has selected HTTP
for its transfer protocol, presumably because they anticipate that most
orders will be placed by a human using a browser. But even the
transmission between the buyer's computer and the supplier's computer
appears to require HTTP (Correct me if I misunderstand; the spec -- at
http://www.supplyworks.com/obi -- is pretty large)


>-----Original Message-----
>From:	Rik Drummond [SMTP:drummond@xxxxxxxxxx]
>Sent:	Tuesday, June 24, 1997 9:03 PM
>To:	'Peter Rawlinson'
>Cc:	'ietf-ediint@xxxxxxx'
>Subject:	RE: EDI over http?
>
>Should we focus on Http or stmp (as discussed below) for doing real time EDI?
>
>What do others think?
>
>Later, Rik
>
>-----Original Message-----
>From:	Peter Rawlinson [SMTP:PeterR@xxxxxxxxxxxxx]
>Sent:	Friday, June 20, 1997 6:08 PM
>To:	'Carl Hage'; 'ietf-ediint@xxxxxxx'
>Subject:	RE: EDI over http?
>
>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.
>>
>>
>