Title: RE: [ebxml-msg] RE: COnformance Clause
Chris:
My whole point about CPP vs. conformance level (in Doug's comment),
is simply that I would try to avoid describing conformance in terms of CPP.
Rather, I would tell which feature modules the MSH supports (a "level"
being simply a subset of these).
Supporting a feature module will in turn allow for many CPP instances a user may
be interested in. (e.g. the Security module will allow for many combinations
of DeliveryChannel Characteristic attribute values - authenticated, confidentiality, etc.-,
or of RM attr values. I guess these may get changed more often than the MSH impl a user uses.)
Now, a vendor (or anyone) may provide a tool that, given a user's CPP - or a CPA- tells
what MSH features are required to support it, as this mapping is not always straightforward.
I guess that is what Doug really wants.
Back to the conformance clause the IIC recommends:
(I'll try to shake out a nascent reputation of regulation freak here...)
Vendors remain free to implement the feature combination they want.
But we believe the certification and testing process that is behind the conformance clause,
is better off with fewer options to target. That is really what it is about.
Few conformance options would also shape a more homogeneous MSH market, I admit,
and we think that is not bad...
So with our proposal there would not be a certification stamp matching each possible
feature combination on the market.
Some other comemnts in line.
Regards,
Jacques
-----Original Message-----
From: Christopher Ferris [mailto:]
Sent: Wednesday, December 05, 2001 10:13 AM
To: Jacques Durand
Cc: 'Doug Bunting';
Subject: Re: [ebxml-msg] RE: COnformance Clause
I believe that it is the prerogative of the OASIS Messaging TC
to determine what is core, not IIC. If there is disagreement
among the IIC members as to what should be considered core, then
I would encourage them to formally join the Messaging TC so that
they can make their views count through votes.
<JD>
The IIC only makes a recommendation here, we do not challenge the MS TC prerogatives.
One of the clause options I submitted has in fact a very minimal basic level.
Almost like in current core (except for Security...)
</JD>
That aside, let me explain why RM is not in core ( as I believe
that is the one which seems to be the most contentious of the
"optional" features/modules.) The RM protocol is provided for
use with protocols that are inherently unreliable such as HTTP
and SMTP. If the ebXML MS were bound to a reliable protocol,
then the RM feature would be unnecessary overhead. In addition,
since the RM feature is fairly heavyweight, it seems to me
that a perfectly valid use of the ebMS is in "best effort"
mode for use by SMEs lets say to enable them to conduct
business, yet without the overhead of full-blown reliability.
In conjunction with a synchronous use of the ebXML MSH,
RM is also potentially unnecessary overhead for a simple
implementation.
<JD>
I see your point for RM (and I guess Ordering) not a core feature, though
then the level of control (that can be seen as QoS) assumed by the current CPP/CPA
might not be available anymore if this is supported at protocol level
(e.g. retries, persistduration, etc.)
I guess the MSH profile you mentioned ( HTTP/S transport binding + RM module)
would then become just an alternative in CPP ReliableMessaging elt.
It Seems to me that the same reasoning apply to Security as well
(e.g. a non-MSH SOAP node can take care of signing messages).
I was not the only one to question Security singled out in core in last f-2-f,
that is what I meant by "not everyone agree" to what is in the core.
(I am not sure I can make a motion on this, as I am not a voting member yet)
</JD>
...
A conformance clause for the ebMS spec should be (IMO) that
an complaint/conformant implementation SHALL pass the test
suite defined <a href="here">here</a> by the OASIS ebXML IIC TC.
For optional features, if supported, then the corresponding test
cases must be passed. For unsupported features, the test assertion
may fail...
<JD>
Conformance clause can indeed - in addition - point to a test procedure - we should add that when available.
</JD>
