headers
AJAY | 2 Jul 1997 19:22
Picon
Picon

Question on OBI - pseudo EDI translator


I read the OBI 1.0 specs (very professionally done, excellent reading material). On page 80 of Section 5.5
titled OBI Order Format Specification, it suggests that "implementation should not require the use of
EDI translator" even though the order request and order data is in EDI format (X.12 850). It would be
appropriate to provide an IC number to the way implementation or use of 850 is suggested (fully edi
compliant IC).

It seems to me that what is intended is a flat-file which immitates segment ids(BGM, REF etc) as record ids
(instead of HDR or DTL records) which integrates with the business application directly. This in my
opinion only adds to the complexity of the business app. In fact  the business app is now required to develop
a mini edi translator. I agree that a "loaded" mapper is not required but it is probably wrong to say that edi
translator is not required. In fact most implementations would prefer to have a mini-edi translator also
in place.

Please correct my understanding. 

Thank you,

Regards,

 <at> jay
Permalink | Reply | 0 comments |
headers
Rik Drummond | 2 Jul 1997 16:57

RE: EDI over http?

Carl's comments have merit on not using either smtp or http for EDI, just use ssl. Anyone else.

At this time we have three proposals for doing interactive/real-time EDI: 1) smtp, 2) http or 3) ssl.  Any
others before we focus. Please make sure you have read the posting by Lincoln a couple weeks ago on the
requirements for this area.

Later, Rik

-----Original Message-----
From:	Carl Hage [SMTP:chage <at> rahul.net]
Sent:	Monday, June 30, 1997 3:01 AM
To:	ietf-ediint <at> imc.org
Subject:	RE: EDI over http?

On Fri, 27 Jun 1997, Andras Salamon wrote:

> Basic SMTP does not have sufficiently powerful mechanisms for a two-way
> information flow.  The server-side responses are essentially three-digit
> numeric codes, so it becomes necessary to either send server-generated
> information in the text comments (for instance message identifiers or
> transport acknowledgements), which is nonstandard, or a separate return
> SMTP message needs to be used, which increases the nondeterminacy and
> ordering problems.

SMTP is one way "push" delivery of messages (including replies), not
ideal for two way messaging. Using nonstandard text or a weird new
protocol would be inappropriate.

In the AS1 model, a return message is always used to deliver a signed
reciept. Ordering is outside the scope of the transport.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rik Drummond | 2 Jul 1997 18:45

RE: EDI over http?

ESMTP maybe should be investigated, maybe a simple extension would give us what we need to do process to
process / real-time / interactive EDI.

Anyone want to do a quick investigation into ESMTP?

Later, Rik

-----Original Message-----
From:	Peat [SMTP:peat <at> erols.com]
Sent:	Wednesday, July 02, 1997 11:41 AM
To:	Rik Drummond
Subject:	Re: EDI over http?

Is there a hybrid approach, sort of go with http or ssl (we need to pick
one - I vote for http), and if timeout, or selected send via smtp? I would
like to think future systems could do this sort of cut-over or transaction
processing.

My two cents.

- Bruce Peat

FYI:  On another note, it was discussed at Microsoft that future versions
of Exchange would switch out X.400 for SMTP as its native interface and is
considering going with XML as its native storage protocol instead of text. 
This fits in nicely with their Zero Admin plans while being able to handle
5,000, 000 users in an Exchange cluster - end of 1998 with the ability to
handle various types of objects.

Reference: http://www.geocities.com/WallStreet/Floor/5815
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Darnell | 2 Jul 1997 19:03

RE: EDI over http?

Rik and Carl,

I like what Carl is saying and think SSL is a better choice than smtp or http.

But what about PPTP (Point to Point Tunneling Protocol) or IPSec where you
could have multiple secure IP connections?

This is how I am establishing Internet enabled backup and disaster recovery
services for several of my clients.

I could see where an EDI hub could be set up like this to do real-time EDI
with its spokes. No need for SSL library calls.  Just set up the encrypted
"tunnels" for each spoke using the same PKI (Public Key Infrastructure)
technology that SSL uses.

There could be a problem with this technology if the trading partner base
is large.  SSL is in all our browsers and PPTP or IPSec client/server
software is not as widely available (although it is now in WinNT 4.0 -- and
a client is available now for Win95).

Just another idea to consider.  I would like to hear from anyone with ideas
on the pro's and con's of this concept.

Regards,
dave_d

At 09:57 AM 7/2/97 -0500, Rik Drummond wrote:
>Carl's comments have merit on not using either smtp or http for EDI, just
use ssl. Anyone else.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Rawlinson | 2 Jul 1997 19:20

RE: Question on OBI - pseudo EDI translator

Ajay
>From my understanding, OBI is stating that a full-blown commercial EDI
translator is not required for the translation of Order Requests, and
that a simple mapping function would do, both at the supplier and the
buyer sides.

Pete

>-----Original Message-----
>From:	AJAY [SMTP:sanghi <at> giasdl01.vsnl.net.in]
>Sent:	Wednesday, July 02, 1997 1:23 PM
>To:	'ietf-ediint <at> imc.org'
>Subject:	Question on OBI - pseudo EDI translator
>
>
>I read the OBI 1.0 specs (very professionally done, excellent reading
>material). On page 80 of Section 5.5 titled OBI Order Format Specification,
>it suggests that "implementation should not require the use of EDI
>translator" even though the order request and order data is in EDI format
>(X.12 850). It would be appropriate to provide an IC number to the way
>implementation or use of 850 is suggested (fully edi compliant IC).
>
>It seems to me that what is intended is a flat-file which immitates segment
>ids(BGM, REF etc) as record ids (instead of HDR or DTL records) which
>integrates with the business application directly. This in my opinion only
>adds to the complexity of the business app. In fact  the business app is now
>required to develop a mini edi translator. I agree that a "loaded" mapper is
>not required but it is probably wrong to say that edi translator is not
>required. In fact most implementations would prefer to have a mini-edi
>translator also in place.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rik Drummond | 2 Jul 1997 19:40

RE: Question on OBI - pseudo EDI translator

I spent 1 hour scanning the document a week or so ago.... It has two focuses: 1) the process issues are very
well described for open buying on internet, and 2) the technology.  I think the technology part needs a few
of small adjustments: 1) they don't use MIME, they seem to define a new data structure, kind of object
oriented, and they use pkcs7, but not s/mime.... to name a few.

They don't really seem to need a translator as Peter says. It is all Web based as far as I can tell.

I thought it was very well done by the way and is a major advancement on the process side. Again, I think it
needs a little work on the technology side to align it with other internet efforts.

Later, Rik

-----Original Message-----
From:	Peter Rawlinson [SMTP:PeterR <at> intelisys.net]
Sent:	Wednesday, July 02, 1997 12:20 PM
To:	'AJAY'; 'ietf-ediint <at> imc.org'
Subject:	RE: Question on OBI - pseudo EDI translator

Ajay
>From my understanding, OBI is stating that a full-blown commercial EDI
translator is not required for the translation of Order Requests, and
that a simple mapping function would do, both at the supplier and the
buyer sides.

Pete

>-----Original Message-----
>From:	AJAY [SMTP:sanghi <at> giasdl01.vsnl.net.in]
>Sent:	Wednesday, July 02, 1997 1:23 PM
>To:	'ietf-ediint <at> imc.org'
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rik Drummond | 2 Jul 1997 19:45

RE: EDI over http?

Good points....Ya know,  this establishes the secure process to process connection, but does not
establish the protocol for the exchange of the data objects. Would we not have to establish a new protocol
or use something like smtp, esmtp, http, or ftp inside of these?

later, Rik

-----Original Message-----
From:	Dave Darnell [SMTP:dave_d <at> systrends.com]
Sent:	Wednesday, July 02, 1997 12:04 PM
To:	Rik Drummond; 'Carl Hage'; ietf-ediint <at> imc.org
Cc:	David Bennett
Subject:	RE: EDI over http?

Rik and Carl,

I like what Carl is saying and think SSL is a better choice than smtp or http.

But what about PPTP (Point to Point Tunneling Protocol) or IPSec where you
could have multiple secure IP connections?

This is how I am establishing Internet enabled backup and disaster recovery
services for several of my clients.

I could see where an EDI hub could be set up like this to do real-time EDI
with its spokes. No need for SSL library calls.  Just set up the encrypted
"tunnels" for each spoke using the same PKI (Public Key Infrastructure)
technology that SSL uses.

There could be a problem with this technology if the trading partner base
is large.  SSL is in all our browsers and PPTP or IPSec client/server
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Rawlinson | 2 Jul 1997 19:56

RE: EDI over http?

Rik
I think the use of IP connection could run into some difficulties.  I
can't immediately see the benefit in using a new port, when HTTP is a
well established medium for 'dropping off' information over 80.  Company
firewall policy will be far more 'agreeable' over the established port
80, rather than a 'proprietary' standard which adopts IP connection over
another designated port.  Additional testing would have to be conducted
to confirm prevention of malicious acts using this port.

By the way, have you heard of the IETF doing any work with the Templar
solution for Real Time EDI?  Maybe we could levergae some information
from this.

Pete
>-----Original Message-----
>From:	Rik Drummond [SMTP:drummond <at> onramp.net]
>Sent:	Wednesday, July 02, 1997 10:58 AM
>To:	'Carl Hage'; ietf-ediint <at> imc.org
>Subject:	RE: EDI over http?
>
>Carl's comments have merit on not using either smtp or http for EDI, just use
>ssl. Anyone else.
>
>At this time we have three proposals for doing interactive/real-time EDI: 1)
>smtp, 2) http or 3) ssl.  Any others before we focus. Please make sure you
>have read the posting by Lincoln a couple weeks ago on the requirements for
>this area.
>
>Later, Rik
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rik Drummond | 2 Jul 1997 18:40

FW: Requirements Doc for Process-to-Process EDI

Erron, this was thought to be the requirement (framework) for real-time/ process to process EDI over
internet. If it is not or needs additions please let me know.....  Thanks for the comments...keep'm up.

Later, Rik

-----Original Message-----
From:	Lincoln Yarbrough [SMTP:lincoln <at> actracorp.com]
Sent:	Thursday, June 19, 1997 5:51 PM
To:	ietf-ediint <at> imc.org
Subject:	Requirements Doc for Process-to-Process EDI

Rik Drummond wrote:
>
> Let review the discussion we had on this late last year and our
> resultant requirement document. Lincoln, if you still have the copy of
> our real time requirement document the wg did last year and you
> edited please distribute to the lists.

HERE IT IS, FROM 3-DEC-97. -Lincoln

                      AS#2 Requirements
                      Straw Poll Results
                          02-Dec-96

Dear Rik:

Here are the results of the informal straw poll, with the original, raw
requirements submitted by the entire group presented in Appendix A.

 -Lincoln Yarbrough
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rik Drummond | 2 Jul 1997 21:16

RE: EDI over http?


-----Original Message-----
From:	Peter Rawlinson [SMTP:PeterR <at> intelisys.net]
Sent:	Wednesday, July 02, 1997 12:57 PM
To:	'Rik Drummond'; 'Carl Hage'; 'ietf-ediint <at> imc.org'
Subject:	RE: EDI over http?

Rik
I think the use of IP connection could run into some difficulties.  I
can't immediately see the benefit in using a new port, when HTTP is a
well established medium for 'dropping off' information over 80.  Company
firewall policy will be far more 'agreeable' over the established port
80, rather than a 'proprietary' standard which adopts IP connection over
another designated port.  Additional testing would have to be conducted
to confirm prevention of malicious acts using this port.
[>>]  

what does everyone else think?

By the way, have you heard of the IETF doing any work with the Templar
solution for Real Time EDI?  Maybe we could levergae some information
from this.
[>>]  

Why don't you explain this in more detail.

Thanks Peter

Later, Rik
(Continue reading)

Permalink | Reply | 0 comments |

Gmane