headers
rsr | 1 May 1998 19:14
Picon

Forwarding for EDI interchange

Dear Mr Drummond and members of EDIINT,

In the IETF-EDI approach, when a received EDI interchange has to be
forwarded . Does this steps necessary:
1. The EDI UA passes the interchange to a translator. Then, a human
operator or a process decide to forward it according information as
interchange sender or EDI message type and so on.Then, the same message
is translated again and forwarded by the UA .
or
2. it supposes the existence of a process that can understand differents
EDI syntax to take decision of forwarding.

Lamia Ben Azzouz
Tunisia School of Informatics
Permalink | Reply | 2 comments |
headers
Rik Drummond | 1 May 1998 16:26

RE: Forwarding for EDI interchange

Often the EDI data is opaque, buried in the s/mime structure. So if
information in the EDIFACT or X12 or Other EDI envelope is necessary for the
decision, the only way to do this is to remove the information from the
s/mime wrapper first before making a decision on where to forward it.

What is the application that would be doing this forwarding or rerouting?

Regards, Rik

> -----Original Message-----
> From: owner-ietf-ediint <at> imc.org [mailto:owner-ietf-ediint <at> imc.org]On
> Behalf Of rsr
> Sent: Friday, May 01, 1998 12:14 PM
> To: ietf-ediint <at> imc.org
> Cc: Rik Drummond
> Subject: Forwarding for EDI interchange
>
>
> Dear Mr Drummond and members of EDIINT,
>
> In the IETF-EDI approach, when a received EDI interchange has to be
> forwarded . Does this steps necessary:
> 1. The EDI UA passes the interchange to a translator. Then, a human
> operator or a process decide to forward it according information as
> interchange sender or EDI message type and so on.Then, the same message
> is translated again and forwarded by the UA .
> or
> 2. it supposes the existence of a process that can understand differents
> EDI syntax to take decision of forwarding.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carl Hage | 1 May 1998 18:13

RE: Forwarding for EDI interchange

> From:          "Rik Drummond" <drummond <at> onramp.net>

> the only way to do this is to remove the information from the
> s/mime wrapper first before making a decision on where to forward it.
> 
> What is the application that would be doing this forwarding or rerouting?

I would look at it as a plug-in to the secxure email software that 
processes the MIME described in the IETF-EDI spec. It might call a 
filter/check program to examine the content of the message, then 
return a forwarding address and whether or not to issue an MDN.

Perhaps the best way to look at the "application" is something that 
looks at the message, then returns the status and parameters for an 
MDN (or an indication to inhibit the MDN), and can optionally provide 
an address or address list for forwarding, and might indicate the 
name of a log file.

> > -----Original Message-----

> > 1. The EDI UA passes the interchange to a translator. Then, a human
> > operator or a process decide to forward it according information as
> > interchange sender or EDI message type and so on.

A person might dispatch a message, e.g. orders are screened centrally 
and then routed to a regional center. Normally, the EDI messages 
would be checked automatically, and an MDN issued automatically. The 
application processing the EDI message (e.g. displaying it to a 
person on a screen) dealing with forwarding should have the original 
message-ID available and could issue a forwarding command to pull the
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. David MacDonald | 1 May 1998 18:53
Picon
Favicon

Status of EDI-over-FTP?

I checked the EDI-INT archives for discussions about EDI-over-FTP. There was
a lot of discussion in the early days as to the pros and cons of it (mostly
the cons).

here's what I've gleaned from the substantial body of knowledge in the
archives regarding EDI over FTP:
- too application/implementation specific to make it interoperable on a
large scale
- lots of problems going through corporate firewalls
- loopholes in FTP specification (open to hacking attempts)
- not a message passing architecture
- "EDI over HTTP" is probably better for point-to-point implementation

What is the status of FTP with regard to EDI-INT?  In the early days, it
seems like it was to be included in the EDI-INT specification but got
dropped along the way.

Was it simply de-scoped from the specification (ie. to be included at a
later date) or were there too many problems with it to justify inclusion in
the specification?

For large corporate clients (ie. thousands of transactions per day), is
EDI-over-HTTP the recommended point-to-point mechanism?

Regards,
Dave
Permalink | Reply | 1 comment |
headers
Rik Drummond | 1 May 1998 19:23

RE: Status of EDI-over-FTP?

You summarized it well. HTTP/post is the direction for file transfers
because or the fire wall problems with ftp.

Will HPPT/post work for you?

Regards, Rik

> -----Original Message-----
> From: owner-ietf-ediint <at> imc.org [mailto:owner-ietf-ediint <at> imc.org]On
> Behalf Of J. David MacDonald
> Sent: Friday, May 01, 1998 11:54 AM
> To: ietf-ediint <at> imc.org
> Subject: Status of EDI-over-FTP?
>
>
> I checked the EDI-INT archives for discussions about
> EDI-over-FTP. There was
> a lot of discussion in the early days as to the pros and cons of
> it (mostly
> the cons).
>
> here's what I've gleaned from the substantial body of knowledge in the
> archives regarding EDI over FTP:
> - too application/implementation specific to make it interoperable on a
> large scale
> - lots of problems going through corporate firewalls
> - loopholes in FTP specification (open to hacking attempts)
> - not a message passing architecture
> - "EDI over HTTP" is probably better for point-to-point implementation
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. David MacDonald | 1 May 1998 19:58
Picon
Favicon

Re: Status of EDI-over-FTP?

Rik,

At this point, I think I'm fighting an unawareness problem with our
participants.
Fortunately, we're only at the "discovery" stage.

Can't see any problem with implementing the HTTP/Post method, technically
speaking.
Will have to investigate more, though.

Regards, Dave
-----Original Message-----
From: Rik Drummond <drummond <at> onramp.net>
To: J. David MacDonald <david.macdonald <at> sympatico.ca>; ietf-ediint <at> imc.org
<ietf-ediint <at> imc.org>
Date: Friday, May 01, 1998 1:25 PM
Subject: RE: Status of EDI-over-FTP?

>You summarized it well. HTTP/post is the direction for file transfers
>because or the fire wall problems with ftp.
>
>Will HPPT/post work for you?
>
>Regards, Rik
>
>> -----Original Message-----
>> From: owner-ietf-ediint <at> imc.org [mailto:owner-ietf-ediint <at> imc.org]On
>> Behalf Of J. David MacDonald
>> Sent: Friday, May 01, 1998 11:54 AM
>> To: ietf-ediint <at> imc.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. David MacDonald | 1 May 1998 21:12
Picon
Favicon

Re: Status of EDI-over-FTP?

Scott,

You're just the type of guy I've been wanting to talk to.

Here's a scenario.

A shipper in the U.S. wants to send goods internationally.  The shipper must
do some or all of the following:
A) Determine the Carrier he wants to use (i.e. Airborne Express, Fedex, UPS,
etc.)
B) Determine an "Export Broker" for the Transaction (multiple ones to choose
from).
C) Determine an "Import Broker" for the Transaction (multiple ones to choose
from).

One he as done this, he must (from a single order-entry type application):
A) Send EDI document to the selected Carrier
B) Send EDI document to the selected Export Broker
C) Send EDI document to the selected Import Broker
D) Send EDI document to the Importer (or Purchaser)
E) Send EDI document to any other interested parties in the transaction

If the shipper were dealing with only a few parties repetitively, then:
    FTP "or something like it" would work
    MQ would work
    HTTP would work
    SMTP would work

However, when the Shipper is dealing with a many players in the trade chain
in a non-repetitive fashion, everything falls apart:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Darnell | 1 May 1998 15:39

Re: Status of EDI-over-FTP?

There still may be hope for using FTP for Internet EDI.

Has anybody looked at the "Secure FTP" product that COMM-PRESS is selling?

I talked with the guys at the COMM-PRESS booth at the DISA conference in
Orlando and it sounds like it solves some problems with FTP.  The word is a
very large retailer will roll out Internet EDI to all their trading
partners with this product.  And it will traverse the firewalls of the
VAN's selling Internet access via their IP EDI trading partner networks
(e.g. IBM Global Network/ Advantis).

My worry is that HTTP/Post just is not robust enough for the high end EDI
programs (My largest client sends out 2 to 20 megabyte EDI invoice
transmissions on a regular basis -- yes, one was 20 megabytes!).

In the retail industry the transactions are getting huge, especially the
ones like the 852 Product Activity Data.  Internet EDI is really the only
cost effective solution for this level of EDI.

By the way, standard FTP through the IBM GN's SOCKS firewall to the
Internet does work fine (I have used it - but only for non-EDI production
file transmissions).  But, there is that problem with standard FTP's
unencrypted user id's and passwords.

Regards,
Dave

At 01:58 PM 5/1/98 -0400, J. David MacDonald wrote:
>Rik,
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
J. David MacDonald | 1 May 1998 23:14
Picon
Favicon

Rik, What's up with your e-mail?

Tried to send you something and got the following:

The original message was received at Fri, 1 May 1998 17:11:13 -0400 (EDT)
from:
   ----- The following addresses had permanent fatal errors -----
<drummond <at> onramp.net>

   ----- Transcript of session follows -----
... while talking to mailhost.onramp.net.:
>>> MAIL From:<david.macdonald <at> sympatico.ca> SIZE=6217
<<< 518 <david.macdonald <at> sympatico.ca>... UCE-domain-block SPAM/UCE received
from your site, Contact Admin.
554 <drummond <at> onramp.net>... Service unavailable

Regards,
Dave MacDonald

E-mail: david.macdonald <at> sympatico.ca
Phone: (613) 825-6183
Permalink | Reply | 0 comments |
headers
J. David MacDonald | 2 May 1998 00:56
Picon
Favicon

Fw: Status of EDI-over-FTP?


>Scott,
>
>You're just the type of guy I've been wanting to talk to.
>
>Here's a scenario.
>
>A shipper in the U.S. wants to send goods internationally.  The shipper
must
>do some or all of the following:
>A) Determine the Carrier he wants to use (i.e. Airborne Express, Fedex,
UPS,
>etc.)
>B) Determine an "Export Broker" for the Transaction (multiple ones to
choose
>from).
>C) Determine an "Import Broker" for the Transaction (multiple ones to
choose
>from).
>
>One he as done this, he must (from a single order-entry type application):
>A) Send EDI document to the selected Carrier
>B) Send EDI document to the selected Export Broker
>C) Send EDI document to the selected Import Broker
>D) Send EDI document to the Importer (or Purchaser)
>E) Send EDI document to any other interested parties in the transaction
>
>If the shipper were dealing with only a few parties repetitively, then:
>    FTP "or something like it" would work
>    MQ would work
(Continue reading)

Permalink | Reply | 0 comments |

Gmane