[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Party Proposal, and am I missing anything here???
William, As Chris has said, it's time to leave the topic of support for intermediaries behind us. We've made that decision, let's move on. Or, if you "can't see much objection", why are you objecting? The ebXML Registry may eventually provide the value you describe. Even if it does, performance may require avoidance of lookups in the central repository for every document flowing through an intermediary. Separately from any performance issues: Not only do organizations have preferences about how they are identified, but they also have preferences about how they identify others. In TRP we're addressing (no pun intended) routing issues. In that part of the e-Commerce infrastructure, it's very important that clients provide enough information that servers can easily forward, authenticate and process their requests. Hence a need for identifiers in the intermediary's preferred identification scheme. Since there may be multiple intermediaries that are not known to the client when composing the message, there's no place to inquire which identification scheme might work best. We need to identify all parties in multiple identification schemes. thanx, doug ------ Doug Bunting cXML Standards Manager Ariba, Inc. -----Original Message----- From: William J. Kammerer [mailto:firstname.lastname@example.org] Sent: January 11, 2001 11:32 To: ebXML Transport (E-mail) Subject: Re: Party Proposal, and am I missing anything here??? Doug Bunting shared with us his proposed changes to the Message Service Specification 0.91, adding "It's insufficient in a multi-hop situation to identify any party using a single scheme (DUNS, SCAC, EAN, whatever). Without explicit prior agreement on identification schemes for all parties, it's probably insufficient for ebXML to allow only one identifier per party even in single-hop situations. This was issue 10 in our list." I can't see much objection to identifying either the <From> or <To> party with one or more <PartyId> elements; after all, just about every organization on the planet has a myriad of ways to identify itself using an ID assignment from any number of internationally recognized authorities. But I think it's a little redundant. Some folks have a preference for how they are identified - some might choose a DUNS, others an EAN, still others a HIN, etc., as we've discussed at length before. Any one should sufficient for tracking down the destination party. All of the relevant IDs for a party should be in the global Registry/Repository within that party's profile (akin to the UDDI identifierBag). Surely, a powerful, omnipotent and all-encompassing registry and repository ("Oz"), which can track down all the plumbers in Cleveland, Ohio (to take one of the examples in a RegRep e-mail) or tell me who will sell me car stereos and does Rosetta Net PIP3A4 (a use case in ebXML Registry Services Version 0.82), could do something as simple as giving me the public key, the HTTP URL or SMTP e-mail address for the MSH, and other miscellany of my partner - assuming I can give it a list of IDs on which it can search. And once I have a way to point my ebXML message to that partner, encrypted with his public key, whatever do I ever need a VAN (or for that matter, multi-hop) for? William J. Kammerer FORESIGHT Corp. 4950 Blazer Memorial Pkwy. Dublin, OH USA 43017-3305 +1 614 791-1600 Visit FORESIGHT Corp. at http://www.foresightcorp.com/ "Commerce for a New World"
Powered by eList eXpress LLC