Re: [ebxml-cppa-negot] Message Content Update based on last conf call

[Heiko Ludwig <hludwig@us.ibm.com>]

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