RE: [ebxml-cppa-negot] Re: Negotiation pattern, transactions, CPP A

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

Title: RE: [ebxml-cppa-negot] Re: Negotiation pattern, transactions, CPPA

Lengthy response.  I will keep my comments realitive to the Collaboration Protocol Agreement Simple Negotiation [CPA-SN] model that I just sent out [http://lists.oasis-open.org/archives/ebxml-cppa-negot/200203/msg00025.html].

1  Race Conditions
==================
1.1 New Offer Scenario
----------------------
> As to (1), we can't avoid that but we still need to figure out
> who gets the ball next if the two parties have both each other
> sent initial requests.
        [http://lists.oasis-open.org/archives/ebxml-cppa-negot/200203/msg00012.html]
Description: Party X and Party Y not having done business together, or wish to establish some other CPA for a new aspect of some business, concurrently send CPA offers to each other.

In this case, there are two (or more) offers corresponding to the uniquely identified CPAs in each offer (uniqueness as definied by the tuple {CPA id, id of party offering the CPA}).  The CPA negotiation application should be smart enough to catch this situation of *apparently* concurrent offers, raise a flag, and then let the humans take over.  After all, the business goals of the offered agreements may be completely different (you could have multiple CPAs between the same parties for different purposes).  In other words, in this scenario, you don't know that the offered CPA are for the same purpose until you compare them.

1.2 Concurrent Counter-Proposal Scenario
----------------------------------------
Description: Party X and Party Y both send CPA counter offers after a CPA offer/counter-offer has been rejected (by either party).

The CPA-SN model does not allow this.  The situation of a party that sends an offer/counter-offer out of turn is easily detected through the application of the model which also requires that the offered CPA has a unique identifier that both parties must use in the collaboration instance.  If a party changes the CPA id, then by definition, a new CPA Simple Negotiation collaboration has been initiated.

2  Reject-with-Counter-Offer-Advice with Counter Proposal
=========================================================
>2. packaging this counter-pending response with the new request
>providing the proposal (plus NDD if needed)
>   --to cut down on message traffic,
>   --to keep related messages "together"
[http://lists.oasis-open.org/archives/ebxml-cppa-negot/200203/msg00015.html]
>1. Can I send, in one message, both my counter-pending
>and my proposal? If not, why not?
[http://lists.oasis-open.org/archives/ebxml-cppa-negot/200203/msg00011.html]

With CPA-SN, counter proposals are NOT packaged in the offer response message (which includes the Reject-with-Counter-Offer-Advice reply.  Bob and Dale have discussed this in http://lists.oasis-open.org/archives/ebxml-cppa-negot/200203/msg00014.html, http://lists.oasis-open.org/archives/ebxml-cppa-negot/200203/msg00016.html.

This constraint is what makes the CPA-SN model not-complex and easily implementable -- the model could be easily implemented by a some hosted application on some website where the "messaging" is between web browsers and the application.  Simplicity out-weighs message traffic for this model.  Keepling related messages together is simply accomplished by the unique id on the CPA being negotiated and, if necessary (but hopefully not), the conversation ids on the message headers.

TO DO: in the CPA-SN model, the CPA Offer Response needs to contain the CPA id of the offered CPA.

3  Proposing/Accepting a Previous Offer
=======================================
>2. Can I send later an Accept for the original
>proposal? (After my counter got nowhere).
[http://lists.oasis-open.org/archives/ebxml-cppa-negot/200203/msg00011.html]
> Dale> It may not be necessary to do this, but one of
> our use cases for counterproposals is that a proposal
> has come in that is acceptable to us, but we think
> that there is another that is preferable.
[http://lists.oasis-open.org/archives/ebxml-cppa-negot/200203/msg00018.html]

With CPA-SN, you simply offer the original offer or a previously rejected offer when it is your turn.  I would recommend providing a note on the offer stating what is going on.  Note that I interpreted "proposal" as "offer" in my readings of the above quoted text. CPA-SN does not have a proposal collaboration (which is partially modeled in the ebXML E-Commerce Patterns [bpPATT] technical report).

TO DO: in the CPA-SN model, the CPA Offer and CPA Offer Response needs to contain note elements.

The CPA-SN assumes (but does not require) that there are humans (or perhaps monkeys) evaluating the offers/counter-offers.  More than likely, the negotiating parties will do some of the negotiation discussion in teleconferences, in person, or other not-modeled means. We could put this interaction into the model and I have often thought that some audiences need it for some models (for example, sellers can send order responses that act as change orders -- what is missing from most models of this process is the phone call where the seller calls the buyer and asks if it is okay to change the order).  In any case, since we probably want to allow the collaboration to not require "out-of-band" communication, the offer and offer response messages should allow for notes.

4 Issue of Non-Terminating Negotiation
======================================
I think it was Dale who pointed out the scenario of the non terminating offer counter-offer negotiation.  I know that there are negotiation techniques to handle this; but, it is out of scope for the CPA-SN.  Some of these techniques could be employed in a proposal collaboration (the CPA-SN only includes the Offer).

The parties can employ simple or sophisticated CPA negotiation application that uses the CPA-SN.  This application can can keep track of previously offered CPAs to offer advice and to help prevent the non-terminating negotiation.  A simple application may not contain this functionality and the user may need to rely on memory and previously hard-copied offers to see that the negotiation is not terminating in a timely fashion.

Let us not forget the telephone, e-mail, and the note elements on the messages that can be used to discuss the situation with the other party.

5 Scope of CPA-SN (Collaboration Protocol Agreement Simple Negotiation)
=======================================================================
The CPA-SN is modeled after the Simple Contract Formation Pattern as specified in ebXML E-Commerce Patterns [bpPATT] technical report ([bpPATT] also discusses more complex patterns). CPA-SN may not meet all the requirements documented in the CPPA Negotiation Requirements document. If this is the case, I would recommend that the CPPA Negotiation team have more than one CPPA Negotiation business process.  Adopt a simple one, such as CPA-SN, as soon as reasonably possible and then later develop more sophisticated ones.

Best Regards,
Brian