Re: [ebxml-cppa-negot] Future document

["Monica J. Martin" <Monica.Martin@Sun.COM>]

> 1.2 Which BPSS Instance Document? Are you talking about the 
> Negotiation BPSS Instance document or the BPSS which are in the 
> parties CPP? I assume you are talking about the Negotiation Business 
> Process otherwise  if a CPA can have more than one CollaborationRole 
> per PartyInfo you might deal with more than one BPSS.
>
> MWS:  Yes, it's the BPSS in the Parties' CPPs.  The Negotiation BPSS 
> instance document can't be negotiated.  It defines the negotiation 
> protocol itself.

mm1: Is this an item that should be addressed in collaboration with ebBP 
sometime in the future in v2?

>
> 1.3 I thought that once you agree on an element you cannot change your 
> mind again might be a problem. Especially in case of interdependencies 
> (use case necessary in the way of if both parties do not talk about a 
> SecureTransport they cannot change the 
> BusinessTransactionCharacteristics 
> (isConfidentail,isAuthenticated,isTamperProof or 
> isNonRepduationRequired) attribute which asks for a SecureTransport 
> element). On the other hand this could be good as one party then is 
> assured, that once value is set it is set. Otherwise you might end up 
> in a loop, like in a game where both players repeat the same move 
> again and again because they think thats the only way to go.
>
> Might be difficult to provide a fair list which elements you allow to 
> renegotiate.
>
> MWS: You are exactly right.  That's why we now say "no going back".  I 
> will add your comments to the futures document.

mm1: This brings up the point if they negotiate items that are in 
conflict with the assumptions in the BPSS instance document (for 
example, message level assumptions that may conflict with the business 
level definitions). I understand that CPP/A can override BPSS defined 
parameters, but what of the business agreement. Is this a potential work 
item for ebBP or between ebBP and CPPA (team and negotiation team)? 
Maybe I am misinterpreting?

>
> 1.5 I came across this one as well. It can also happen, that one party 
> sends an accept message even though there are still open negotiation 
> items in the NDD. This is probably against the negotiation protocol 
> (negotiation rules) and the receiving party will return with an error 
> message. According to the BPSS an accept message can be sent no matter 
> if there any open issues.
>
> MWS: Correct.  The BPSS instance document does not define the whole 
> protocol.  An implementer MUST read and obey the textual description 
> as well as the BPSS instance document.
>
> 1.5 But I agree that there might be a message back and forth in the 
> form of "we are done, what do you think?".
>
> MWS:  I assume you mean an acknowledgment message that might be sent 
> by the recipient of the final CPA (where there is no signing) or the 
> double-signed CPA (where there is signing). I will put this suggestion 
> in the futures document.
>
> 1.6 Ordering Dependencies among Negotiable Items. For some reasons I 
> was believing that all Negotiation Items are negotiated in parallel. 
> Have to recheck in the ANCPA.
>
> 3. Negotiation Algorithm - I start to have problems to see the border 
> between the internal "negotiation" process and the collaborative 
> negotiation business process. To which business process does the rules 
> for the game, for example, once an item is accepted it is accepted 
> belong to? The internal business process must know this rule, I think. 
> If it belongs to the internal business process you/we might start to 
> differentiate between these two business processes.
>
> MWS:  As above, that's why we left the negotiation algorithm for the 
> future.
>
> 7. Simplification of Negotiation - You might provide a default 
> negotiation algorithm specification/report which does only negotiate 
> "simple" things. If there are simple things at all :)
>
> MWS:  I will put this comment in the spec both under negotiation 
> algorithm and under simplification.
>
>
> Other questions/thoughts
> ------------------------
>
> o Did you every think of not having everything negotiated in parallel? 
> Unfortunately I did not think through an example but negotiating 
> everything in parallel seems to be more difficult than negotiating one 
> by one. As mentioned above I might have misunderstanding here.
>
> MWS:  I am not sure what  you mean by "parallel".  By "parallel", do 
> you mean that everything negotiable is in the NDD at the start? If 
> so,  the idea was to present everything that is negotiable at the. 
> Probably, the "easy" items can be negotiated in one pass.  In any 
> case, each party has the option of accepting as much or as little as 
> desired in each iteration and continuing the string of offer-counter 
> messages as long as needed, thus producing serialization.
>
> o For some reasons I still think that when a negotiation starts both 
> parties first have to agree on the CPA template and the NDD for that 
> CPA template. Instead of having to reject and restart a new 
> negotiation some Business Transactions Activities could be added to 
> cover a "setting" stage first. Saying that, the acceptance of a CPA 
> template and NDD might also end up in a offer - counter offer - 
> counter offer scenario until the negotiation over the elements of the 
> NDD starts.
>
> MWS:  I think that your real concern is the NDD.  The NDD says what is 
> negotiable in the CPA Template. The whole negotiation process consists 
> of step by step refinement of the CPA Template until it becomes a 
> complete CPA. To me the extra step of negotiating over the NDD would 
> be excess complexity. If the recipient of the initial offer doesn't 
> like the NDD, the recipient should reject the initial offer and get on 
> the phone. I believe that in most cases where both Parties have 
> published NDDs for their CPP, the NDD in the initial offer will be 
> acceptable since the offering party MUST use both NDDs in constructing 
> the NDD for the CPA Template. If so, then adding negotiation over the 
> NDD is function that will be mostly not needed but adds complexity to 
> the spec and cost to the implementations.  A Party that does not 
> publish an NDD for its CPP is implying that everything is negotiable 
> and ought to be willing to negotiate with any NDD that comes in an 
> initial offer, though we can't require that.
>
>
>
> *************************************
> Martin Sachs
> standards architect
> Cyclone Commerce
> msachs@cyclonecommerce.com
>
>
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/ebxml-cppa-negot/members/leave_workgroup.php. 
>
>