[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa-negot] Message Content Update based on last conf call
Bob and everybody, I guess we did understand the pattern. We are reiterating the last two last phone calls here. The diagram in the "Patterns" document certainly does not exclude race conditions, although it states the requirement in plain English (p17). I liked the "nested sub-transaction approach" that was proposed by Pallavi, I think, the counterproposal being a new sub-transaction of the original one. This would allow counteroffers to be sent in one message, within the requesting activity of the new transaction. The top-level transaction could be completed later with a response indicating the overall result of the negotiation. One could read this in the diagram that you sent but I guess this is not what you mean. To resolve the need for plain English description on how two transactions should be linked, I propose to describe the negotiation process as a state diagram of one party, not as the state o fthe process as a whole. This is what vendors have to implement anyway. Heiko bhaugen <linkage@interaccess.com> on 03/05/2002 08:12:33 AM To: Dale Moberg <dmoberg@cyclonecommerce.com>, Jean Zheng <Jzheng@vitria.com>, ebxml-cppa-negot@lists.oasis-open.org cc: Subject: Re: [ebxml-cppa-negot] Message Content Update based on last conf call Dale and all, Are you sure you understood the simple negotiation pattern? Or maybe it wasn't explained well enough in the document? The negotiation stage is supposed to be transactions with alternating sides, as long as a counter-offer is pending (as long as the negotiation is still alive). The diagram in the document maybe did not make that crystal clear. Attached is one that might. >One drawback to the way we are thinking >of things now is that one can respond to >a "request" with another "request," which is >probably outside the current request-response >pattern. We are still seeking BPSS advice on >this situation. That is one of the reasons why the simple negotiation pattern has every counter-offer as a new request with an obligatory response. >There are also some "race" conditions that >others can discuss For example? I'm not saying the simple negotiation pattern is perfect, but there were a bunch of smart people at the table, and we had reasons for every decision. >Meeting is Wednesday if you want to help! Ok, I'll try to join the conference call at least for a while. -Bob Haugen ----- Original Message ----- From: Dale Moberg <dmoberg@cyclonecommerce.com> To: bhaugen <linkage@interaccess.com>; Jean Zheng <Jzheng@vitria.com>; <ebxml-cppa-negot@lists.oasis-open.org> Sent: Monday, March 04, 2002 9:06 PM Subject: RE: [ebxml-cppa-negot] Message Content Update based on last conf call Hi Bob, One "meta-requirement" on CPA negotiation is that the semi-automated negotiation process converge rapidly either by failing (and throwing the process up to humans for resolution) or succeeding (for the parameters marked negotiable in a NDD, which iconstrains what is up for debate). One phenomena we wish to avoid in the semi-automated "dumb" negotiation is one in which the sides just iterate back and forth endlessly in a "RSA-SHA1" "DSA-MD5" loop (you can add some other dimensions of oscillation, and backtracking, if you want to make the failure to converge less obvious). By starting a new transaction, we retain no history and we do not really have a chance to switch "sides" on who is constructing the initial proposal and whose NDD governs the search for acceptable parameter values. The Simple Negotiation process builds in no assurance that each side has a chance to let its NDD and its draft CPAs come up for consideration. There are also some "race" conditions that others can discuss. The upshot is that the Simple process seems a bit too simple to have the desired behavior. One drawback to the way we are thinking of things now is that one can respond to a "request" with another "request," which is probably outside the current request-response pattern. We are still seeking BPSS advice on this situation. Meeting is Wednesday if you want to help! Dale Moberg -----Original Message----- From: bhaugen [mailto:linkage@interaccess.com] Sent: Monday, March 04, 2002 6:27 PM To: Jean Zheng; ebxml-cppa-negot@lists.oasis-open.org Subject: Re: [ebxml-cppa-negot] Message Content Update based on last conf call Re tentative process: is there some reason that you abandoned the original idea, which I thought was to use the ebXML v 1.0 Negotiation Pattern. That would require each offer in the negotiation to be enclosed in its own transaction with either a success, fail or counter-pending post condition. In other words, each offer could be explicitly and clearly accepted or rejected. If you just go back and forth with counter-proposals, I think it will be more difficult to determine what was accepted or rejected. (Which was one of the ideas behind the Pattern.) -Bob Haugen ----- Original Message ----- From: Jean Zheng <Jzheng@vitria.com> To: <ebxml-cppa-negot@lists.oasis-open.org> Sent: Monday, March 04, 2002 7:19 PM Subject: [ebxml-cppa-negot] Message Content Update based on last conf call I've made some update to Message Content based on our discussion during last conference call. Main Changes are: 1. add in a Security section for "InitiatingCPANegotiation" message. 2. Add in enumerated list for CPA status and reason for rejection. 3. Move Tentative Process section to the end. Any help in adding more details to any of these sections are very welcome! Especially in the Security section. Thank you! Jean
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC