RE: [ebxml-msg] Messaging Spec v1.092 / CPA dependency

Jacques,

You have given a very good summary of the situation.

I have several times suggested the expression "Configuration Parameter
Aggregation" as a nickname for CPA but so far no one has shown interest.

IMHO, the problem here is that some people want the richness of ebXML
messaging but do not accept the need to configure a pair of partners to use
the richness.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown
Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************

Jacques Durand <> on 01/10/2002 07:45:26 PM
To:
"'David Fischer'" <>, Martin W

Sachs/Watson/IBM@IBMUS, Jacques Durand <>
cc:
ebXML Msg <>
Subject:
RE: [ebxml-msg] Messaging Spec v1.092 / CPA dependency

I believe the notion of "independence" should remain "formal": means
an MSH instance is not required to imperatively access an ebXML CPA server
somewhere,
or is not forced to literally parse a CPA document.
I think it satisfies the spirit of the charter, the ultimate purpose of
which is
I believe that any MS implementation should be able to work without a
(formally)

CPA-compliant implementation.

That does not mean an MSH should not use any "CPA-data"... which should be
considered
as MSH configuration data, as Martin suggested. Being able to configure MSH
behavior
at conversation level, not just message level, makes it a much more
reliable/efficient
�tool for business, and so it is worth the pain of sorting out the semantic
conflicts
between this configuration data and header data.
If we don't do it, then each message will have to always carry CPA-data,
and the burden will be on the app to provide it each time.
Plus, in future versions, the MSH will likely be the place where to enforce
CPA data
that is higher level than message: duration of a conversation, max
concurrent conversations...

Maybe the apparent dependency is mostly editorial.
we could have abstracted more the notion of CPA in MS spec:
Just a (late) suggestion: we could have named it "Communication Protocol
COnfiguration" (CPC)
and assume it is no more than a set of attributes associated with each
communicating pair (from/to), and write CPC anywhere we use CPA today.
We could have then a RECOMMENDATION that the CPC content be derived from a
CPA...
So applying a CPA to an MSH is a matter of configuration, in the same way
as applying a
CPA to a lower transport layer is.

Jacques