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

[bhaugen <linkage@interaccess.com>]

<Dale Moberg>
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.
</Dale Moberg>

1. Why is that better than just allowing somebody
to restate the same offer again when it is their
turn?

2. In the Simple Negotiation Pattern, if anybody
rejects an offer outright, with no counter-pending,
it's the end of the negotiation, and if anybody
wants to continue, they restart from the top.

3. If you stick to the existing ebXML transaction
model (which I think you can do), won't your
overall problem be simpler?  (Use any compliant
software, etc. etc.)

<Dale Moberg>
(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"
</Dale Moberg>

But it doesn't keep some related messages together.
The critical relationship is offer-acceptance.  If you
send the counterproposal with the response, you
lose that relationship, and will need to recapture it
with some other logic.  So what did you gain?
A few seconds in a very intermittently used process?

<Dale Moberg>
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.
</Dale Moberg>

Actually, I think human negotiation patterns have
already been simplified.  I agree that automated
processes do not necessarily need to adhere to
the human patterns, but I have also seen people
go deep into the technical bag of tricks when
it's not necessary, because the humans have
already shown how to simplify the problem.

-Bob Haugen

P.S. I'll try to stop arguing now and just answer
questions.