OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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.
 
3Three 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]