[ebxml-iic-conform] about conformance levels

[Jacques Durand <JDurand@fsw.fujitsu.com>]

Title: about conformance levels

Mike, Matt (& al):

Important when defining conformance profiles/levels:

Last November a vote was taken in IIC about MS conformance levels
(as it is in the charter of IIC to define these)

I am attaching the results, which show that the TC decided to
require the implementation of "Business-level" quality of service
features such as Security, Reliability, Ordering (even though of course users
do not have to use these features which are CPA-controled.),
so that there is clear value added by MSH implementations over
basic messaging, and interoperability with these features would be
possible across all MSH. I think we should comply with this decision.

I am attaching the details of the conformance levels for vote (the spec section numbers
may not match anymore, but the features are clearly described).
Note that the TC voted for a very limited set of conf profiles (two) so that
interop would not be threatened, yet made it possible to not implement
some features relevant to very specific configurations (multi-hop).

NOTE:

You'll find mentions of "strong" vs. "weak" conformance in these conformance definitions.
(The "strong" interpretation is required per IIC vote). It is also required now in the
MS spec:
A short definition of "strong" conformance is defined as follow in the current MS 2.0 spec
(though no explicit use of this term) :
-----------
".It complies with the following interpretation of the keywords OPTIONAL and MAY: 
When these keywords apply to the behavior of the implementation, the implementation
is free to support these behaviors or not, as meant in [RFC2119]. 
When these keywords apply to message contents relevant to a module of features,
a conforming implementation of such a module MUST be capable of processing these
optional message contents according to the described ebXML semantics."
(so that means in case the module is implemented - as it may not if optional -
then it must be able to process such optional message features.)
-----------
(The "weak" conformance would allow an MSH to NOT implement the processing of
optional material in a message. MS TC agreed that was not good.)
I am also attaching a precise definition by IIC.
You'll notice that in the IIC def, "SHOULD / RECOMMENDED" features MUST actually also
be implemented in order to be "strongly" conformant (again the concern is here to ensure
maximum interoperability).
Hope that helps...

Regards,

Jacques

 

Attachment: IIC_MSConfClause_vote.xls
Description: MS-Excel spreadsheet

Attachment: CC_option_1.doc
Description: MS-Word document

Attachment: CC_option_2.doc
Description: MS-Word document

Attachment: CC_option_3.doc
Description: MS-Word document

Attachment: CC_definitions.doc
Description: MS-Word document