RE: [ebxml-cppa-negot] Minutes of Mar. 20, 2002 conference call

["Hayes, Brian" <Brian.Hayes@Commerceone.com>]

Comments:
> Dale wondered if the BPSS instance would be negotiable.  
> Marty suggested that agreement on one BPSS instance out 
> of several possibilities could be useful but we should 
> not get into negotiating the contents of a BPSS instance.

I agree with Marty.  Negotiation of the CPA overridable contents of a BPSS
instance is done in the CPA and is thus done during the CPA negotiation.
Some other team could develop the collaborative process for developing BPSS
instances... does anyone want to form a BPSS Development Process TC??? :^)

> Dale also wondered if roles are negotiable.  For example, 
> there might be business processes where either party 
> could play either role. 

I think in this case, the CPA just simply has an entry(ies) for the party
playing one role and for the party playing the other role.  With the v0.06
CPA Simple Negotiation Business Process Model, there is an implied CPA where
the two parties are signed up to play the roles of CPA Negotiator A (the
initiator of the collaboration) and CPA Negotiator B.

>Brian's initial draft has party A always sending offers and 
> Party B always sending counter offers.  We will need to be 
> sure that this is sufficiently flexible.
>The draft assumes that offer and counter offer have the same 
> structure, i.e. the same schema.

In an email I sent earlier, I essentially confirm this.  However, just to be
more accurate, Party A always initiates the business transaction identifed
as "Offer CPA" and Party B always initaties the business transaction
identified as "Counter Offer CPA."  The first "Offer CPA" transaction
contains the initially offered CPA and all subsequent transactions are
counter-offers regardless of the business transaction identification. 

> Jean pointed out that we will need some kind of metadata that 
> link a counter offer to the corresponding offer and to support 
> retry after message losses.

I'm not convinced.
Scenario A: 
     1) I don't recieve a reciept acknowledgement, acceptance
acknowledgement, or CPA Offer Response with the specified time period (see
sections 8.1.2 and 8.2.2 of the v 0.06 model).  2) The Business Transaction
Property Value for the Initiating Business Activity Recurrence (retry) count
is set to 0. Thus, the business transaction fails per UMM semantics (see UMM
Patterns document). 3) The collaboration goes to FAILURE (Oops, this
condition is not shown on collaboration diagram; but, is hopefully provided
by UMM and BPSS semantics ;^). 4) I ponder why the other party ignored my
offer after their system sent back a receipt acknowledgement and acceptance
acknowledgement within the prescribed time. 5) If I want to do business with
them, I call the other party on the phone.
     Note that this scenario applies with any business transaction instance
at any time during the collaboration instance.

Scenario B:
	We redefine the Business Transaction Property Value so the
Recurrence (retry) count for the Initiating Business Activity is 3 (or some
other non-zero value). 1) I don't recieve a reciept acknowledgement,
acceptance acknowledgement, or CPA Offer Response with the specified time
period. 2) I reinitiate the business transaction per the BPSS/UMM semantics.
3) If I don't recieve a reciept acknowledgement, acceptance acknowledgement,
or CPA Offer Response with the specified time period, I go to step 2) unless
I've already reached the recurrence/retry limit. If I hit the
recurrence/retry limit, the business transaction fails and the collaboration
subsequently fails.

Scenario C:
	We redefine the Business Transaction Property Value so the
Recurrence (Retry) count for the Initiating Business Activity is 3 (or some
other non-zero value). I switch roles in this scenario: I recieved an CPA
Offer and I respond with a CPA Offer Response.  But, I notice that my CPA
Offer Response never appears to properly make it to the destination because
I never recieve an acknowledgement reciept or acceptance acknowledgement
(see sections 8.1.2 and 8.2.2).  I cannot resend the CPA Offer Response
because the BPSS and UMM semantics do not allow it (my guess is that the ISO
Open-EDI reference model doesn't allow it either).  I can pick up the phone
a call the other party or wait. Say I wait. Eventually, the other party will
resend the CPA Offer (because the Recurrence/retry count is non zero).  My
CPA negotiation software will easily detect that the CPA Offer to be a
duplicate or that the other party is acting out of turn.  From there it can
do what I command it to do like resend my original response.
     How does my software easily detect or consider the CPA Offer to be a
duplicate?  First, I keep a transaction log of all transactions against the
CPA-Offer business object instance in my system.  Second, if I assume that
the other party did not get my CPA Offer Response, then the received CPA
Offer should be a duplicate.  If I assume that the other party did get my
CPA Offer Response but their receipt acknowledgement or acceptance
acknowledgement did not get to me, then I know they must be acting out of
turn in the collaboration instance (recall that you can Accept, Reject, or
Reject-With-Counter-Offer-Advice).  If they recieved my rejection, they
shouldn't be sending me anything unless they are trying to initiate a new
negotiation.  If they recieved my acceptance, they shouldn't be sending
anything.  If they recieved my reject-with-counter-offer-advice, they should
be waiting for me to respond.
     Moral of the story: if you don't recieve an acceptance acknowledgement
(or perhaps a receipt acknowledgement), call the other person up on the
phone.

> Jean said that we still need to decide whether to send 
> a complete draft CPA back and forth during the negotiation 
> process.  

I assume that by "draft CPA", you mean a non-binding CPA -- something you
would exchange in a CPA Proposal collaboration and not in a CPA Offer
collaboration.


I appologize for missing the last conference call.  I had a last minute
12:00 PST appointment.

Best regards,
Brian