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
- From: James Bryce Clark <jamie.clark@mmiec.com>
- To: Martin W Sachs <mwsachs@us.ibm.com>, moon4u@posdata.co.kr
- Date: Sun, 31 Mar 2002 23:11:17 -0800
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]
Powered by eList eXpress LLC