[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Multi-BP CPAs (TP teleconf 2-28-01)
Super work Jamie. Works for my business, after I read your explanation which someway needs to reflect back in some final documentation to the general public when we're all done ! Dave > -----Original Message----- > From: James Bryce Clark [mailto:jbc@lawyer.com] > Sent: Thursday, March 01, 2001 1:54 PM > To: ebxml-ccbp-analysis@lists.ebxml.org; ebxml-bp@lists.ebxml.org > Subject: Multi-BP CPAs (TP teleconf 2-28-01) > > > For those of you who are following CPA-BP collaboration > dependencies, I > wanted to pass along these matters from the 2/28 TP conference call. > > This is one of two messages, one e-mail per topic. Words in > quotes below > are loosely rather than strictly employed. Sorry, but I am > trying to grope > towards simple understandings of complex things. > > Multi-BP CPAs > ------------------- > > In a CPA, parties may "approve" their future use of a BP by > including a > reference to (or digest of) a ProcessSpecification document > that "defines" > a method for that BP for those two parties. A single CPA might also > "approve" the use of 30 different bilateral BPs, in collaborations or > otherwise. > > The question came up yesterday whether a CPA that "approves" > 30 different > BPs should be capable of incremental amendment without > requiring a new CPA. > I think not. Trading partners may wish to enter into long term > arrangements (like purchase agreements) that rely on the continuing > availability of multiple BPs (like change orders or returned goods > protocols). Also, as a practical matter, as we've discussed > in BP, CPA > formation may to be the obvious (and sometimes only) exposed > control point > for institutional channel management of these e-transactions. > So I am not > too keen on permitting incremental modification to a CPA > without explicit > renegotiation of the whole set of BPs embodied in it. > > So I shilled for the following outcome, which I think has > been accepted by > TP: > (a) If you have an XML-DSIG-signed CPA "approving" 30 BPs, > the sig will > hash over the whole set of 30. Thus, if you try to assert a > change in one > BP, the sig will be invalidated, as a few bits have been > jostled, forcing > the parties to renegotiate the CPA. > (b) If trading partners want to be able to do 30 different > things, with > no dependencies, they may enter into 30 distinct CPAs. > > <minutes excerpt> > >It was noted that when a CPA references multiple > >Process-Specification Documents, it should be assumed that those > >processes are interrelated and invalidating the CPA and all of the > >Process-Specification documents when a problem develops with one > >of them is the correct action from a business viewpoint. > </minutes excerpt> > > Please let me know if anyone thinks this is the wrong > conclusion, in which > case, I need to go do some groveling in TP. Jamie > > James Bryce Clark > Spolin Silverman & Cohen LLP > 310 586 2404 jbc@lawyer.com > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: > ebxml-ccbp-analysis-request@lists.ebxml.org >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC