Multihop and Pull

["Pim van der Eijk" <pvde@sonnenglanz.net>]

Hello,

 

Line 998-1000 of ebMS 3.0, Part 1, Core Spec states:

 

"If no explicit assignment is requested (e.g. by the message Producer at Submit time or per configuration of the MSH), the default MPC name "http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/defaultMPC" is assigned."

 

Line 1048-1050 goes on to state that:

 

"A PullRequest signal message always indicates in its header (see Section 5.2.3.1) the MPC on which the message must be pulled. If no MPC is explicitly identified, the default MPC MUST be pulled from. The pulled message sent in response MUST have been assigned to the indicated MPC. "

 

I think we should relax this in the case of multi-hop, especially now that we seem to agree that we don't want to support multihop PullRequest. I.e. the MPC mentioned in the PullRequest is only relevant for the "next MSH". Suppose we have a large intermediary (e.g. ISP or next-generation VAN) that offers ebMS 3 MPC "mailboxes" to hundreds or thousands of small businesses. The idea of sending to pulling from a default MPC does not make sense here. Core v3.0 would seem to require all senders to any of these small businesses to insert a unique MPC attribute in the ebMS message, possibly duplicating information in the ebMS header like To/PartyId or Service. Each MPC would also need to be globally unique.

 

Especially in the case of multihop we should support a mechanism where the intermediary can assign messages that do not have a value for eb3:UserMessage/@mep (and perhaps even messages that do have such a value) to MPCs based on some classification logic. E.g. one MPC for each To/PartyId, multiple ones for distinct Party/services combinations, or one MPC for large messages and another for small messages etc. Products could differentiate in providing added value here.  The only change in the spec would be to change MUST to SHOULD or MAY.

 

Pim

 

---