Title: RE: [ebxml-msg] Re: Use cases for messageOrdering
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
----- Original Message -----
From: Jacques
Durand
To:
Cc: Jacques Durand
Sent: Monday, 03 December 2001 14:11
Subject: [ebxml-msg] RE: COnformance Clause
Hi all:
In order to
prepare for the conformance agenda item (next conference call, next
week)
here are the two candidate conformance clauses for MS 1.1 that are most favored by the
IIC group (Options 2 and
3),
for your review. (Option 1 was "all
or nothing" conformance.)
A
conformance clause should normally be included in the final spec
document.
IIC is
actually recommending Option 2 ( 9
members preferred it, while 4 members preferred option 3)
As voters
could also express - or not - second choices, we actually used a "weighted" vote
that reflects more precisely
the total
preference for each option (weight=3 for most preferred, 2 for second if any is
mentioned, 1 for third if any mentioned).
Result
is:
33 (thirty
three) for Option 2,
30 (thirty)
for Option 3,
8 (eight) for
Option 1.
I think this
vote - starting with the design of the clause candidates - indicates how
important
some features
like Reliability and Ordering have been perceived.
You'll note
that a special attention has been given to the interpretation of the keyword
"optional" , as
this used to
cause some trouble in past MS POC performances (see "definitions").
.
Note
that these clauses define
conformance levels (rather than profiles),
based on implementation
and usage investigation
(see the "rationale" section
at the end)
These levels do not attempt
to match functionally all possible profiles/agreements (CPP/A),
but should
rather be considered as properties of the MSH implementation itself -
establishing a few broad classes of implementations (yet coherent from usage
perspective),
so that the number of MSH
certification options can be limited.
(A same conformance
level roughly guarantees
the same CPA playing field for all communicating parties,
supporting several usage
profiles, the detailed definition of which being done/enforced at
CPP/A level.)
Regards,
Jacques Durand
Fujitsu Software
IIC,
conformance clause group
