Bob, Intentionally I did not put everything in one message, as I don't want to make people choke, and I want to truly explore different possibilities and different options.
As it has been pointed out, the DNS/MX problem does not solve the selection of transport mechanism or security and authentication issues. It tells you where to send the transactions but it does not tell you how to get there. Other mechanisms, such as UDDI, can tell you the rest. I can see how a trading partner would create a transaction with the designation of the "receiver" in the ISA being something like "acmepipe.alliedTPA.hipaa.net" and pass it to their clearinghouse. Up to this point, the translator knows where to send the transaction but does not know how to get it there. So the translator puts the "receiver" in the ISA but no information about the transport layer. The ISA interchange is given to a transport mechanism that looks up the DNS MX record for "acmepipe.alliedTPA.hipaa.net" and finds that there are multiple routes, some through clearinghouses, another one direct, and with different preference factors. This route and transport discovery could be done through UDDI, LDAP, DNS/MX, or other method that is easy to deploy today (that probably rules UDDI out for now). The transport discovery mechanism could take care of digital certificates, telephone numbers, login and password, etc. The trick is to keep separate the "address" in the ISA from the route chosen by the transport layer, because the EDI translator may know the address but probably does not know the route. Then, asthe file with the address in the ISA is delivered to the next hop, each recipient is free to choose the most efficient route for them, without even having to touch the ISA at all. This will facilitate the transfer in between clearinghouses. One of the reasons to use the hipaa.net at the top of this domain pyramid is that it would be trivial to configure the servers, firewalls, and routers to only accept traffic from other members of the hipaa.net domain hierarchy, thus providing some level of deflection against SPAM and against intrusion. Not real security, but one more barrier for intruders. And, if we use the DNS/MX records, it will help keep the EDI servers separate from the mail servers even though both have MX records. I never said the solution I am presenting would solve all the problems, but at least solves the "address" problem and takes a step toward solving the "routing" problem. Security, support for legacy dial-up connections, etc. are still to be (sic) addressed. Kepa [EMAIL PROTECTED] wrote: > Kepa, > > I appreciate your tutorial. > > I agree that this is a valid and desirable vision for the future, when we > can pull routing together with security, authentication and > non-repudiation. I share that vision. At that point, except for the HIPAA > definition of Clearinghouse as format converter, the distinction between > clearinghouse and VAN ceases to exist. > > The question becomes, how far away is that future? And, is that future the > focus of this group. > > That vision does not fit with our current reality of point to point > interchanges with clearinghouses needing/able/choosing to break apart > interchanges and transactions and construct new ones that combine > information from multiple ultimate senders to get it to multiple ultimate > receivers. > > So, the question becomes - is this group looking to address (no pun > intended) the short, mid or long range routing/addressing issues? > > Bob
