[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC