Multihop and Pull

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