RE: [ebxml-dev] ebXML CPA/CPP Estimate

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Bernd Eckenfels writes concerning

Mike Rawlins> A few caveats to this analogy: 
> Exchanging information securely over the
> public Internet using the ebXML
> MHS requires more configuration
> options  to be specified than is the
> case with a typical EDI system.

"This is especially true, if digital signatures and certificates are
involved. Those have to be exchnaged anyway. Therefore retrieving a CPP
may help, and having a CPA helps even more. On the other hand,
exchanging the CPA also requires a already working infrastructure, which
means, most of the parameters the CPA can deliver are already set up."

Dale Moberg> If there were no working infrastructure already, 
do you really think these people were going to succeed in
collaboration? Most of the parameters are there in software to be
set up, true. But which way? 

The CPP and CPA are exchange formats, Bernd,
and you seem to be missing this crucial point. Writing down
a CPP presupposes you have working software that implements
some portion of a specification's described capabilities.
This happens on both sides. Is there an overlap in that
set of capabilities? If so, you can write 
down a CPA that expresses
the agreement for your interoperation in that collaboration
and send it to them out of band or, when possible, in
a to-be-defined light-weight communication mode.
Not a big deal to do perhaps, but useful. URLs are pulled out,
and service names, action names, PartyIds, and several
things to populate fields in ebXML messages. Retry counts,
time out intervals, persist durations, whether to use
digital envelopes, how the response is returned (whether
synch in a HTTP reply, whether asynch in some other
connection (URL for that?), or whether some mix. And that
is just a start. You may wish to make customers pick
and choose values for all those technical matters, 
and then deal with the resulting support. And did I hear
you say you wanted this to roll out to SMEs? 

"Instead of configuring a system with 
lots of parameters from a CPP I
vote for specifying reasonable defauts 
for all those parameters. This is
much more cost saving on the SMB case."

Gee Berndt, I don't know how we missed this!
Next time you should come to a meeting and 
explain to everyone what the "reasonable defaults"
on all transport, acknowledgement, NRR,
reliable messaging, signals, signatures,
trust anchors, certificates, digital envelopes,
transport security should be for all types of
all business collaborations (from product
announcements to authorization for fund
transfer) for all variety of organizations
(government, educational,
Fortune1000, SME, midsize, and so on).
We could use your help! You might also find
out why this approach never works in practice,
and why we have _options_. Then you will understand
why we are trying to make configuration
of options easier, and to arrive at interoperable
solutions even when options exist. No wonder
you agree with Mike.