William, I started reading through the draft spec. for ebXML CPP and it looks like everything we have been talking about is addressed. I've inserted a summary of the "PartyInfo" section below. The Transport elements section should be able to specify all those legacy dialup settings you mentioned. I understand Dick Brooks was also looking at this. I wonder if anyone is actually "hooking up" via a simple CPP-CPA negotiation... and then passing plain old EDI interchanges.. and then un-hooking.
This does imply the existence of a [simple?] CPP registry in which each Collaboration Protocol Profile is an XML document indexed with a globally unique ID number... which could be either the ProviderID or the PlanID. Each of these XML documents can be digitally signed, so it would seem that all trading partners could upload new/signed CPPs whenever local conditions changed. Each time a sender wants to transmit an interchange, it appears that he would just query the national Plan or Provider CPP registry, auto-negotiate a CPA (essentially an electronic trading partner agreement for that one interchange... TPA could be logged) which would, in turn auto-configure his system with all the transport/addressing details... click SEND! Has any "industry" grabbed hold of this yet? We have a relatively "blank-slate" in vision care and the manufacturers, labs, and other entities in the eye doctor's supply chain are meeting next month for a high level discussion of doctor-lab EDI... VERY high level. The host entity, Vision Council of America is already thinking about handling some or all of the "standards maintenance" issues associated with a Doc-Lab purchase order standard. They might be willing to maintain an ebXML registry for all potential trading partners within the vision industry. Am I understanding this general process correctly? Thanks, -Chris The PartyInfo element consists of the following child elements: · One or more REQUIRED PartyId elements that provide a logical identifier for the 734 organization. 735 · A REQUIRED PartyRef element that provides a pointer to more information about 736 the Party. 737 · One or more REQUIRED CollaborationRole elements that identify the roles that this 738 Party can play in the context of a Process Specification. 739 · One or more REQUIRED Certificate elements that identify the certificates used by 740 this Party in security functions. 741 · One or more REQUIRED DeliveryChannel elements that define the characteristics of 742 each delivery channel that the Party can use to receive Messages. It includes both the 743 transport level (e.g. HTTP) and the messaging protocol (e.g. ebXML Message 744 Service). 745 · One or more REQUIRED Transport elements that define the characteristics of the 746 transport protocol(s) that the Party can support to receive Messages. 747 · One or more REQUIRED DocExchange elements that define the Message-exchange 748 characteristics, such as the Message-exchange protocol, that the Party can support. 749 At 12:23 PM 2/25/02 -0500, William J. Kammerer wrote: >It's unrealistic to restrict transport methods to the common TCP/IP >protocols. We need to support all the "legacy" dial-up connection >types - to assuage fears of the open Internet's security "problems" or >to simply support the PM systems out there already - with some means of >describing scripts, logins, passwords, modem-settings, etc. etc. in our >Electronic Trading Partner Agreement. Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
