Car Is To Truck as EDIINT Is To...

Hmmm...  there is no equivalence to Truck for EDIINT.   Well, maybe you
could say VANs are equivalent but then VANs are proprietary and their
delivery technology unique while EDIINT is open and a well defined
protocol.

Dr. Johnson's situation is that he provides VAN services to his
customers.  He wants to include internet document delivery for his
customers documents to pass through his network.  This reintroduces the
VAN element to the transmission equation, which  is not part of the
EDIINT agenda and should never be.   What Dr. Johnson can do is use the
EDIINT specifications as a foundation for a proprietary internet
solution - but that defeats the whole purpose of using EDIINT as a
protocol.  Another solution is to use the EBXML protocol includes for
pass-through specifications that meet Dr. Johnson's requirements.

There has never been a description for a pass-through function in the
EDIINT specifications.  Why -  because EDIINT's sole purpose is to
provide a protocol for point-to-point delivery of EDI documents using
Internet technology.  EDIINT is not an all encompassing description for
every possible avenue to do document delivery.

MTCW,

Joe McVerry

"Rishel,Wes" wrote:
> 
> There are many reasons for using VANS other than simply getting a secure
> connection. They provide valuable add-on services in many industries.
> 
> Ideally EDIINT would permit connections to and from VANs over the Internet
> as well as connections directly between end-points. (At this point the
> "network" is either the Network or a more secure private IP network.)
> 
> Generally, the value-added services require decoding, examining and perhaps
> changing the payload, so the required key exchange is between the VAN and
> each of the endpoints and the final recipient has to trust that the VAN
> properly authenticated the initial sender.
> 
> -----Original Message-----
> From: David Fischer [mailto:[email protected]]
> Sent: Monday, November 19, 2001 6:48 PM
> To: [email protected]; [email protected]
> Subject: RE: AS#1
> 
> I think it is important to point out that the whole point of EDIINT/AS1 is
> to
> eliminate the use of intermediate VANs.
> 
> AS1 is sometimes used with a VAN but this is not the typical, or the
> intended
> implementation.
> 
> Regards,
> 
> David Fischer
> Drummond Group.
> 
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of
> [email protected]
> Sent: Tuesday, November 13, 2001 4:48 PM
> To: [email protected]
> Subject: AS#1
> 
> I have read eith great interest your MIME-based Secure
> EDI draft document and I have come to a dicovered some
> very serious problems that may diserve special attention.
> 
> In Section 2.3.1 you state: "This specification assumes
> that a typical EDI interchange is the lowest level
> object that will be subject to security services".
> In my view, this assuption is extremely dangerous and
> may be at the heart of several important limitations to
> the present and future use of EDI over internet. The
> lowest level of sercurity services should not be limited
> to an envelope level.
> The next paragraph in your draft points out one
> immediate consequence of the above limitation: In EDI
> terms (ANSI or EDIFACT), that means "anything between
> and including..the envelope segments". "Congruent with
> the above statement, EDI envelop headers are NOT visoble
> in the MIME package. In order to optimize VAN-to-
> internet routing, work may need to be done in the future
> to define ways to pull out some of the envelope
> information to make them sisible, however, this
> specification does not go into any detail on that".
> Indeed, by encrypting the entire EDI interchange,
> including the envelope headers, you are no longer able
> to route the message to/from VANs without decrypting the
> message. This is a serious, and in many cases
> unacceptable limitation.
> In other words, by using S/MIME as the encrypting
> standard for EDI over internet, you are are de-facto
> eliminating the possibility to exchange messages between
> traditional EDI VAN users and new intgernet EDI users,
> unless either or both of these users go though
> a "gateway" to perform the interconnection, and allow
> such gateways to decrypt and encrypt tha messages for
> them.
> The latter is totally unacceptable from a security point
> of view. Furthermore, VANs retain the control over EDI
> message routing and administration, life will not change
> much for current EDI users.
> May I suggest a much more logic, simple approach:
> 1. Use either X12.58 (ANSI) or EDIFACT Security rules as
> defined in the guidelines.
> 2. Secure only the information you wish to secure
> according to the guidelines in 1
> 3. Manage authentication, non-reputiation of origin, key
> management, etc. accourding to EDI rules.
> The above alternative would all EDI translation and
> security software to be compatible regardless of the
> platform, internet protocol, and messaging protocol.
> I know you have worked very hardr with the security
> issues you are trying to resolve, but I have tryed
> several of the ideas you are proposing in your draft and
> I can assure you that that the issues I am addessing
> will surface in the future as companies try to embrace
> EDI/internet.
> Respectfully,
> Dr. Ricardo S. Johnson

-- 
----------- 
Joe McVerry
American Coders Ltd.
POBox 97462
Raleigh, NC   27624  USA
919.846.2014 (voice/fax)
http://www.americancoders.com
Home Of OBOE - an EDI and EDI/XML Translator
    and xBaseJ - xBase Database Engine For Java