RE: Multi-BP CPAs (TP teleconf 2-28-01)

["Welsh, David" <David.Welsh@nordstrom.com>]

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
>