🚀 go-pugleaf

In article <E5v7qE.D85@world.std.com>, jhallen@world.std.com says...
>
>It's time to start "Free EDI".  EDI (Electronic Data Interchange) is an old
>set of document standards designed to allow businesses to communicate with
>each other.  Typical of the business transactions covered by EDI are

Hi Joseph...I really sympathize with the sentiment of creating an open standard 
alternative to EDI. The thing is, we already have one: HTTP and HTML. Before 
you laugh yourself sick, read on :-)

I think it's useful to remember what EDI was originally created for, as you 
point out...

>wholesaler to retailer communications: the retailer sends a PO (Purchase
>Order) to the wholesaler, which then sends the ordered materials to the
>retailer.  Then the wholesaler sends an Invoice to the retailer.
>
...and also remember that this was before every device smarter than a toaster 
had a tcp/ip stack (so I guess this leaves out Ellison's NetPC). Anyway, the 
need was to securely communicate business documents and perform transactions. 
This is taken care of now by HTTP for the communications, HTML for the 
documents/forms, and security can be handled by SSL or S-HTTP. This leaves 
transactions.

And again, we have an existing open standard:CORBA. Not only does this take 
care of the database abstraction layer, but it alleviates all the pain of 
trying to define your own Transaction Processing Monitor (TPM) as you're trying 
to do in another message in this thread, as object-based TPMs are a special 
type of ORB.  

>The second problem is that EDI is only a high-level document standard, not a
>low-level communications protocol.  This has the effect that when two
>
HTTP and HTML take care of that combination.

>To start things off, I'll propose a common structure for Free EDI
>transactions:
>
> - The communications system for Free EDI will be SMTP-TCP/IP Internet
>   e-mail.  The advantage of this is its universality.  Everyone has access
>   to Internet e-mail and SMTP-TCP/IP is very common for "intra-nets" as
>   well.
>
> - Security will be based on the defacto internet security system: PGP. 
>   Each message will have a PGP signature from the sender and will be
>   encrypted with the recipient's public key.  This will be sufficient
>   security so that even EFTs (electronic fund transfers) can occur through
>   Free EDI.
>
As has been pointed out by someone else on this thread, secure MIME specs are 
available, but to secure e-mail and most other documents, I agree that PGP is 
the best way  to go. And, in regards to another message in this thread, it is 
available on all sides of the pond, so should be useful internationally.

The transport mechanism itself for SMTP, though, I don't think should be 
overloaded with setting up and tearing down secure communication channels, and 
I don't think the best method of EFT has an SMTPd in the path.
 
> - Free EDI will be transaction based in the database-locking/rollback sense.
>   Each EDI transaction will be completely executed or have no effect (no
>   partial transactions).  Several transactions can be sent in each email
>   message.
>
Another reason why, for distributed transaction processing across networked 
databases (in case anyone was wondering, I stumbled across this thread in 
comp.databases) to just use existing TPMs. For starters, what mechanism do you 
intend to build into SMTP servers to handle error reporting. You've said you 
won't permit partial transactions, which is good, but for a system that will be 
transferring peoples hard earned money and possibly affect credit ratings, you 
need a real TPM.

> - Transaction IDs will be universally unique.  This will allow Free EDI
>   transactions to be broadcast via USENET or in USENET-like environments. 

EDI spam...I can see it now...I think even considering to use NNTP is even a 
worse idea than SMTP...what happens when someone crossposts a PO :-)

[SNIP: all the data record and table layout...nice job though]

>Please start discussing the sufficiency of this as a data format.
>
One of the problems with EDI is that it trys to be all things to all people. 
99% of those fields will only be used 5% of the time. The strength of the web 
for enabling commerce is that it allows a company to put its order form online 
so someone can order x Widgets. If only certain someones are supposed to see 
certain forms, they can be protected by various means. Companies are already 
sending sensitive documents across the 'net, according to their unique needs. 
Banks are using SSL and S-HTTP, it's how I do my banking...no EDI needed or 
wanted.

-- 
_dave_(seemingly obligatory and definitely bandwidth wasting .sig)