Re: [ebxml-cppa-negot] CPA negotiation simplifications by limiting NDD content

[Martin Sachs <msachs@cyclonecommerce.com>]

Hi Sacha,

Yes, what we had in mind originally was negotation of the straight-forward 
cases that don't require elaborate negotiation algorithms. You are also 
correct that the specification allows for negotiating one or just a few 
items and that it covers the simplest case of "accept or decline but no 
counter offer is allowed". However once you start growing from a few items 
to a lot of items, you then have the possibility of decisions on those 
items interacting with each other (my choice for item A may affect the 
possibilities for item B) and the complexity grows.

Regards,
Marty


At 01:36 PM 11/5/2004, Sacha Schlegel wrote:
>Hi ebXML CPA negotiation team
>
>The CPA negotiation not that complex after all? Simplification by NDD 
>content limitation.
>
>Yesterday I made an interesting observation:
>
>My current work is to analyse the CPA management. One specific example is 
>to handle the situation where a certificate of the CPA expires. The idea 
>is that the party who's certificate expires creates a new certificate, 
>updates the CPA (creates a clone of the previous one and changes cpa id), 
>adds the new certificate and distributes the CPA again. The second party 
>accepts the update and both parties install the new CPA and continue b2b 
>with the new CPA. It does not really matter who initiates this business 
>process.
>
>This scenario lead to the following question whether to use CPA 
>negotiation for this.
>
>So what I actually want is some form of a CPA negotiation. In particular a 
>very specific form of a CPA negotiation. In this CPA negotiation all what 
>has to be negotiated is the <Certificate> element. So instead of having a 
>CPA negotiation which can negotiate about anything of the CPA I want to 
>limit the CPA negotiation to just this "Certificate" negotiation.
>
>So currently two main scenarios are calling for very specific and limited 
>CPA negotiations. These are:
>
>o Certificate negotiation
>o Transport Endpoint negotiation (one partner has a new domain name, or a 
>new port)
>
>These specific CPA negotiations even allow to provide a negotiation 
>algorithm. Some programming code can deal with examining a certificate 
>like is it a valid certificate, doest it belong to the partner, is it 
>trusted (exception of the easy case -> would mean rejection with a 
>reasonable error message (I think the call to have defined error messages 
>was mentioned before))...... more certificate specific tests.
>
>The same is true for Transport Endpoint negotiation. Is it a valid URL for 
>example (there are already libraries out there which just check URL´s), 
>maybe ping it to test if it is alive.
>
>So it will not be hard to have these 2 negotiation algorithms to handle 
>these 2 specific CPA negotiations.
>
>So a CPA negotiation system will grow by one "specific CPA negotiation" 
>after the other.
>
>Counter offers don't even make sense here, the party has to accept a 
>partners new certificate or endpoint address. So if the test of the value 
>is successful the responding party can accept the values and hence the 
>parties would get a new CPA.
>
>So thinking of this, I was wondering that maybe the history of the 
>Automated Negotiation of the CPA was coming from this corner of use cases. 
>Simple use cases such as the two described above lead to the current 
>framework which is open enough to allow also for other elements and 
>attributes to be negotiated. Having made this observation I start to think 
>that it is not that complicated anymore after all. Maybe Marty can comment 
>here. Marty, you seem to have dealt with CPA´s or Trading Partner 
>Agreements even before the official ebXML time.
>
>So the art to learn step by step is to have a simplification by limiting 
>the content in the NDD. For example a first Specification version could 
>only allow to have Negotiation Information Items which reference a 
>"Certificate" and a "Transport/Endpoint" element. One must have done the 
>study what it means to negotiate over other elements and attributes. It 
>will get more complicated when negotiating over elments and its child 
>elements for example and these examples should wait until there is a real 
>use case for them...
>
>The funny thing is that the specification already says that "only what is 
>listed in the NDD is allowed to be negotiated". So if I know that first 
>only a few rather easy elements and attributes are allowed to be 
>negotiated I start to feel more comfortable and think it actually could be 
>applied.
>
>Please let me know what you think.
>
>Regards
>
>Sacha
>
>
>
>
>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.

*************************************
Martin Sachs
standards architect
Cyclone Commerce
msachs@cyclonecommerce.com