CPA negotiation simplifications by limiting NDD content

["Sacha Schlegel" <sschlegel@cyclonecommerce.com>]

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