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



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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC