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

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

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