ebxml-msg — archive

[Jacques Durand]

Sander: From the two alternatives you mention: (a) not bother with the new multi-hop MEP binding lengthy names, since they are "emulated" by combinations of conventional p-2-p MEP bindings already defined in Core V3. (b) the opposite: require that the new multi-hop MEP bindings (which actually specify only the bidings on the "peripheral hops") be used in the P-Modes on each side when migrating to multi-hop. I would still prefer (a). Of course MEPs are likely to be modified anyway in both cases. But in (a): - the Pmode.MEPbinding parameter gives you a clear idea about what kind of communication you'll get with the first (or last) intermediary, in the same way you would describe your interaction with an endpoint MSH. - Also Pmode.MEPbinding will not change in case you want the same communication pattern with your Intermediary as you had with your p-2-p partner endpoint. - So in fact, in several cases the Pmode may have to change on the Sender side but may not have to on the Receiver side. So the definition of new multi-hop MEP binding names in the previous draft was mostly a way to give a name end-to-end combinations of peripheral bindings (sender side + receiver side), and not intended to be used in the Pmode.MEPbinding. But that in itself may be confusing, I agree: we should either go with option (a) or (b), not in-between. The only reason I could see to support (b) is if we want to reduce the supported binding combinations on both ends. The merit of the mapping rules at the end of section 1.8.1, is that each multihop MEP binding clearly spells out the valid combinations on each side. Another reason could be to associate well-defined properties to the multihop MEP, including (implicit?) reply patterns for various signals (RM signals, eb:Receipts and eb:Errors) with these MEP bindings. But not sure that is a real benefit. Jacques