Title: RE: [ebxml-msg] RE: COnformance Clause
I
agree with Jacques that conformance pertains
to the
mandated capabilities of an ebXML MSH,
what
has to be implemented in the software.
These
capabilites may _all_ be advertised in a
CPP or
a CPA-template. But some profile
(that
is some proper subset)
may be
put together that specifies precisely how a
community or a peer intend to operate.
It
would be nice if it worked that way, because
then
most negotiations would succeed between
conforming MSHes! (except for conflicts
about
trustAnchors or related gotchas..)
Dale
Moberg
-----Original Message-----
From: Jacques Durand
[mailto:]
Sent: Thursday, December 06, 2001 8: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>
