RE: [ebxml-msg] RE: COnformance Clause

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

Chris,

Thanks for the clarification. I agree with your point.

-Philippe

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Friday, December 07, 2001 9:44 AM
To: Philippe De Smedt
Cc: Jacques Durand; 'Doug Bunting'; ebxml-msg@lists.oasis-open.org;
karl.best@oasis-open.org
Subject: Re: [ebxml-msg] RE: COnformance Clause


If I left that impression, then I appologize.
What I was trying to convey is that if there are
concerns regarding what is (or is not) normatively defined as
core and optional that they should be discussed
and voted upon within the MSG TC, not IIC.

Cheers,

Chris

Philippe De Smedt wrote:

> 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>
>



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>