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

[Dale Moberg <dmoberg@cyclonecommerce.com>]

I think we should consider, for our purposes,
using a counter-pending response to synchronize
the conversation, but also allow:

1. a flag to indicate that the original proposal (the one this counter 
   is a counter to) is not rejected;
   also, that a separate reject or accept on that is still pending.

    The flag could also indicate firm rejection in the sense that
    this can't work. I think we want to have an error if a firmly
rejected
    proposal gets offered again, unlike with humans.

(and as a useful optimization)

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"

I assume that this optimization could be handled at the message
packaging layer
and need not be reflected in the "logical" description. That may help
map
the process into the Request-Response pattern of BPSS.

I am still curious about using the "nesting" of transactions for our
purposes
as Pallavi brought up. Not sure if it buys us a lot, but it might be
useful
for case 1 above, when the flag is "notRejected" ("stillBeingRanked"?)
 
I do not think we need to be required to capture every feature of human
negotiation in a CPA "negotiation" process. CPA negotiation is not
nearly as nuanced as human agreement/contract negotiation and it does
not seem
critical to me to adhere to the human patterns in these mostly automated
processes. In particular, the rejection semantics should be strong in an
automated process and not just a tactical maneuver. I think it will be
more
complicated to automate otherwise.




-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Tuesday, March 05, 2002 11:57 AM
To: bhaugen
Cc: ebtwg-bps@lists.ebtwg.org; ebxml-cppa-negot@lists.oasis-open.org
Subject: [ebxml-cppa-negot] Re: Negotiation pattern, transactions, CPPA



Bob,

In my mind, we want to permit either party to be able make an offer or
counter offer while avoiding the race conditions.  Your (2) is
interesting.
If I send you a counter-pending response, I am telling you that I want
the
ball to initiate tne next transaction.  I had not thought about that
possibility.

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.

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
************************************************************************
*************


 

                      bhaugen

                      <linkage@interacc        To:       Martin W
Sachs/Watson/IBM@IBMUS                                         
                      ess.com>                 cc:
ebtwg-bps@lists.ebtwg.org, ebxml-cppa-negot@lists.oasis-open.org        
                                               Subject:  Re: Negotiation
pattern, transactions, CPPA                             
                      03/05/2002 01:42

                      PM

 

 




From: Martin W Sachs
> The race condition issue is simply this:  Some protocols might get to
a
> point where the two parties, more or less simultaneously, send request
> messages to each other.  The two requests might be conflicting
proposals
> for some particular aspect of the CPPA being negotiated.  It that
point, it
> may not be clear whose proposal takes precedence.  That in turn could
lead
> to conflicting responses, at which point the state of the draft CPPA
might
> be unclear.

1. How is this different from the situation where two parties,
more or less simultaneously, kick off the initial request
messages to each other?

2. I think of the negotiation pattern as a game, where
the trading partners take turns.  Strictly.  When I send
you an offer, you must respond with either acceptance,
rejection or counter-pending.  You cannot send a counter-
offer without first sending the counter-pending response
and receiving my ack.  Etc.

3. If that is too strict for you (you really want to allow
anybody to make an offer at any time in the collaboration)
then:  if you use the transaction protocol, each offer starts
a separate transaction.  It's the same as #1 above.
(But I wouldn't do that...)

What am I missing?

-Bob Haugen







----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>