RE: [ebxml-msg] RE: COnformance Clause

[Philippe De Smedt <pdesmedt@agentisinternational.com>]

Title: RE: [ebxml-msg] RE: COnformance Clause

All,

 

I'd like to chime in on the issue of prerogatives. As Jacques said, the ebXML IIC TC has no intention of challenging the Messaging TC's (or anyone else's) right to define what they see fit. However, the IIC TC was created with the explicit charter to issue opinions and provide advice on conformance (hence the 'C' in IIC), so I find it rather unfortunate that the work that the IIC TC is doing is now being characterized as infringing on another TC's prerogatives. No issues of that nature were raised when the IIC TC's charter was proposed and voted on.

 

That said, a number of members of the IIC TC are indeed already members of the Messaging (and other) TCs, and have substantially contributed to the creation of the specifications. We also have established formal liaisons with those TCs. David Fischer is the liaison with the Messaging TC, so we do have the mechanisms in place to have everybody heard and to share opinions. If it is the Messaging TC's opinion that the IIC TC is infringing on their work, I'd like to hear it and discuss it, but as far as I'm concerned, the IIC TC is not doing anything outside of the boundaries of its charter.

 

-Philippe

 

chair, ebXML Implementation, Interoperability, and Conformance TC

-----Original Message-----
From: Jacques Durand [mailto:JDurand@fs.fujitsu.com]
Sent: Thursday, December 06, 2001 7:52 PM
To: 'Christopher Ferris'; Jacques Durand
Cc: 'Doug Bunting'; ebxml-msg@lists.oasis-open.org
Subject: 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:chris.ferris@sun.com]
Sent: Wednesday, December 05, 2001 10:13 AM
To: Jacques Durand
Cc: 'Doug Bunting'; ebxml-msg@lists.oasis-open.org
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>