[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC