OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [ebxml-dev] about cpp/a negotiation



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.

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.   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?

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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC