[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-dev] about cpp/a negotiation
Jamie, Thank you for the kind words. A few rejoinders below. Regards, Marty ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* James Bryce Clark <jamie.clark@mmie To: Martin W Sachs/Watson/IBM@IBMUS, moon4u@posdata.co.kr c.com> cc: ebxml-dev@lists.ebxml.org, ebxml-cppa@lists.oasis-open.org Subject: Re: [ebxml-dev] about cpp/a negotiation 04/01/2002 02:11 AM At 06:08 PM 3/31/02, Martin W Sachs wrote: A few clarifications on the exchange below: I have invariably learned from my conversations with the resourceful and urbane Marty Sachs since we first met in the v1.0 round of ebXML. Thankfully, he also has always been gracious about my technical idiocies. This is no exception. Marty is too polite to mention that he heads the negotiation group mentioned below, and he is a wonderful resource on that topic. Party B can't simply accede to Party A's CPP. Party B must also send party A its CPP since that contains information that party A needs in order to exchange messages. In most cases, it will be desirable to compose a CPA based on the two CPPs is the usual next step. The composition can be automated (see discussion in one of the appendices in the CPP-CPA specification). However the composition process may require some negotiation of mismatches. Marty, on re-reading, I agree that my word "accede" oversimplified things. But I wonder by how much? The possibility was much discussed that a frequent trading partner could relieve prospective counterparties of effort -- and itself of a complicated negotiation protocol -- by offering up a buffet platter of plausible and user-friendly CPP alternatives. I see in Appendix F of the May 2001 CPP/A 1.0 spec that this was described as "a CPA template" rather than "composition" from two CPPs. MWS: There is a big difference between a CPP and a CPA template. A CPP is a 1-sided IT profile. It has information about me but not about you. A CPA template is a complete CPA, describing both parties' capabilities, except for a very few elements and attributes that the other party must fill in. For the simplest cases, this information may be just its transport endpoint address and PartyId. If you had said "CPA template" instead of CPP, I would have had no quibbles. But logically we are talking about the same phenomenon, no? One party provides a plausible set of transport, security, etc. elections, optimized for wide adoption. The other reviews it, finds the specified business process agreeable (as a business matter), decides that it can support each of the parameters as proposed (as a technical matter), and then may "sign on" by adding the minimal quanta of its own identifying data and confirming its assert. The 1.0 spec discusses this as something that might be accomplished with very simple tools, at the level of a Web form, at lines 3427-3435. MWS: Again - CPA template vs CPP. A CPA template is most useful in a "take it or leave it" situation. If you want to talk to me, you must comply with the contents of the CPA template that I sent you. Composing a CPA from two CPPs is more for two big guys who both need a say in the final CPA. Your comment ... Party B must also send party A its CPP since that contains information that party A needs in order to exchange messages. ... makes me wonder if we agree about the contents of that minimum quanta. In some trading communities, I imagine the orchestrator or dominant buyer will say "jump", its would-be vendors will say "how high", and there will be nothing left for the latter to 'talk about' other than to send over the equivalent of their address and a signature. Doesn't work? MWS: See my reply directly above. Regards Jamie ~ James Bryce Clark ~ VP and General Counsel, McLure-Moynihan Inc. ~ Chair, ABA Business Law Subcommittee on Electronic Commerce ~ 1 818 597 9475 jamie.clark@mmiec.com jbc@lawyer.com ~ This message is neither legal advice nor a binding signature. Ask me why.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC