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

["Marcia L. McLure Ph.D." <marcia.mclure@mmiec.com>]

Kudos to you Jamie. I concur with Dave....let's get it in writing!
Marcia
----- Original Message -----
From: "Welsh, David" <David.Welsh@nordstrom.com>
To: "'James Bryce Clark'" <jbc@lawyer.com>;
<ebxml-ccbp-analysis@lists.ebxml.org>; <ebxml-bp@lists.ebxml.org>
Sent: Thursday, March 01, 2001 1:56 PM
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
> >
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org
>