The position in the TAB about conformance clause
semantics is (now that a conformance clause is mandatory):
- "claiming conformance to the specification" is
something that can only rely on the conformance clause in the specification
document.
- this conformance
clause may define levels/profiles, so a developer can claim conformance to the
specification "according to level L or
profile P" or the like.
- Any group of users can later on define "profiles" of a
specification, in a separate doc. These
profiles - if in OASIS - define their own conformance clause(s). Implementers and/or users of such profile can then only
"claim conformance to the profile X" of the specification S. Not directly
to the specification S.
That confirms the need to define a
"minimal" clause.
For maximum interoperability and
simplicity, I'd favor option (a) below: If
some products or users want to only support pulling the intermediary on the last
hop, they could define a separate "pulling" profile and claim comformance to
this profile of multihop specification.
- If however we have good reasons to
believe that (1) hub-and-spoke will be a quite common topology, (2) pulling will
be such a common practice that intermediaries should not be required to support
"push" in order to conform to Part 2, then we should consider
(c).
-jacques
Summary of where we are with the conformance clause (CC) for multihop:
1- informal consensus is that the
conformance clause can address a "minimal profile" which is easy to implement,
while reflecting most commonly expected use.
2- current clause for "Simple
Multihop" sets the bar too high w/r to this goal:
Supporting both MEP bridging models (described in 2.5.3)
by Intermediaries: "push-on-push" and "pull-on-push" should not be
required.
Instead, only one should be required.
3- Three options:
(a) the CC only requires push-on-push to be supported.
(and requireing endpoints to support MEPs that push only)
(b) the CC requires either "push-on-push" or
"pull-on-push" or both to be supported.
(c) two CCs are drafted (meaning two ways to conform) that
are very close to each other:
- one requiring "push-on-push" for intermediaries (and
requireing endpoints to support MEPs that push only)
- the other "pull-on-push" (and requireing endpoints to
support MEPs that push for sending, and pull for receiving)
4- Problem with (a):
it forces Intermediaries designed only for pull-forwarding, to also support
push-forwarding.
- Advantage of (a): it is a simple clause, that supports
interoperability.
- Problem with (b): not helping interoperability...
options inside the Clause give little meaning to claiming
conformance.
- Problem with (c): multiplies the conformance clauses (or
conformance profiles), with little differences. Ideally these variants should be controlled by product configuration, not by
product feature implementation choice.
Jacques