[ebxml-iic-conform] about conformance levels

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