Issue about transparent multihop for "Bridged Domains"

Issue: the assumption that 
"transparent multihop" applies to bridged domains (in the same way as it 
applies to Hub-and-spoke and Interconnected-Hubs topologies) is overly 
restrictive:

- In many 
applications, a B2B Gateway is where security and reliability are expected to be 
handled, as what is beyond the gateway is a private domain with QoS needs (and 
contractual needs) different from the public side.

 

Proposal: 

- Make the principle 
of "transparent multihop" just one mode of multihop supported by ebMS part 
2.

In another mode - 
"serviceable multihop" , intermediaries (typically edge-intermediaries) could 
modify the SOAP envelope before forwarding - add/remove security or reliability 
headers, even bundle/unbundle. In both modes, intermediaries never modify User 
Message units or Signal Message units.

- Keep the current 
draft focused on "transparent multihop", but make sure that it does not preclude 
"serviceable multihop" which could be described in a future conformance profile 
(e.g. transparent and serviceable correspond to two levels of conformance for 
intermediaries)

 

-jacques