To restate some of what I said on this topic during the
face-to-face meeting: This seems to be on a collision course with Collaboration
Party Profiles. Rather than having an enterprise say "I support the MSH
features described in the CPP", the IIC team would like them to say "My MSH is
conformant at this level". This doesn't appear particularly worthwhile and
goes against the mix-and-match nature of the features we've included in the
specification.
In reality, there's three levels here:
1. A MSH may support 95% of the ebXML-MSH specification.
Side note: The other 5% MUST result in SOAP mustUnderstand Fault or an
ebXML error. The current IIC definition of "weak conformance" doesn't
seem to require errors when an unsupported features is requested, just
when that feature corresponds to a top-level SOAP extension.
The phrase "behave consistently either as if the feature were absent
from the material..." allows a receiving application to silently ignore requests
for unsupported features, violating the requirements we've
specified.
2. The enterprise managing the MSH may choose to advertise
their support for 75% of the ebXML-MSH specification. They will configure
their MSH to reject requests for the other 25% as described above or no
longer be a conformant MSH implementation.
3. Two parties interacting using their MSH implementations
will choose to collaborate using 45% of the ebXML-MSH specification.
Again, requests for the non-contract 55% over this channel will consistently
result in an error.
While CPP and CPA documents might be used to describe the
supported features at some of these levels, they aren't a necessary
condition.
Depending upon the configuration of the MSH, features rejected at levels 1
and 2 might (MAY) result in SOAP mustUnderstand Fault errors. Because
level 3 rejections require checking the partner agreements and therefore
invocation of the ebXML handler, features rejected at that level should (MUST?)
never result in such a Fault.
I would propose a conformant MSH implementation MUST include
support for all Core Features in the specification and errors MUST result
whenever a request is received for a non-supported, non-configured or
not-contracted feature. Any optional feature implemented MUST be
supported in accordance with the "strong conformance" requirements. That's
it.
Since we've already required most of these errors, it's
unclear a new clause is necessary in the document.
thanx,
doug