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:]
Sent: Thursday, December 06, 2001 7:52
PM
To: 'Christopher Ferris'; Jacques Durand
Cc: 'Doug
Bunting';
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:]
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>
