[ebxml-cppa-negot] Earlier posting by Bob Kearney

[Martin W Sachs <mwsachs@us.ibm.com>]

Bob Kearney and I have discussed his posting of 9/13/02 (below) and the
responses to it. The prior discussion resolved all matters except the
following.  Please comment. For "Acceptance History", a decision isneeded.

ACCEPTANCE HISTORY

The main reason that Bob suggested retaining the full history of
acceptances ("edit history") is because he believes it will make for a
simpler implementation than with each party just keeping it privately.   It
is not a state-tracking issue since each party knows the current state.
Please post views on this:

Should the acceptance history be just the result of the response to the
most recent counter offer or should it contain the entire edit history of
the negotiation dialogue? I don't believe that we can simply recommend
something because both parties to a negotiation would then have to agree on
which alternative to use.

CONFIRMATION OF ACCEPTANCE

 Bob had originally proposed this pattern for the conclusion of
negotiation:
1. A sends B a counter offer
2. B send A acceptance in full
3. A sends B a confirmation of B's acceptance.
4. B sends A the final CPA in a new transaction.

The pattern we are actually using replaces step 3 by "B retains initiative
to start a new transaction".

Bob agrees that the confirmation of B's acceptance is not necessary except
for the case where the confirmation of acceptance is necessary to confirm
that nothing remains to be negotiated (below).

DETERMINING WHETHER ANYTHING REMAINS TO BE NEGOTIATED

Bob believes that there are cases where Party B accept a counter offer and
has nothing further to propose but knows that there may still still open
subjects and that Party A should submit proposals on them.  This can happen
if each party has its own strategy for order of negotiation.  Sending the
acceptance without "counter pending offer" would pass initiative to Party A
to submit the next counter offer. To enable this case, we would need to
provide a message by which Party A tells Party B that he is finished.  Step
3 (above) would consist of either a confirmation of acceptance or a counter
offer from A to B. This is similar to the previously proposed case where
Party B wants Party A to re-present a previous counter offer.  Bob agrees
that this should go on the futures list.

The above is essentially the same function as the previously discussed
procedure for asking the other party to put a prior counter offer (or the
original offer) back on the table. I plan to add the above paragraph to the
discussion that is already in my futures document.

Regards,
Marty


*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************