RE: [ebxml-msg] Summary of where we are with the conformance clause (CC) for multihop

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

From: Jacques R. Durand 
[mailto:] 
Sent: Thursday, March 04, 2010 4:44 
PM
To: 
Subject: [ebxml-msg] 
Summary of where we are with the conformance clause (CC) for 
multihop

 

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