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: RE: [ebxml-msg] Multihop and Pull

That looks like a valid use case.
I see two ways to handle this:
1. As an extension of the routing function, where an intermediary could decide to change the MPC when forwarding a message (or when putting it in a Pull  queue). Problem is that breaks transparency,  and signatures. Introduces security threats.
2. Keep the principle of end to end transparency meaning the message is not altered at all (@mpc does not change.) But allow an intermediary to manage "subchannels" that is when they receive a message over an MPC xyz, they are free to assign it to a new MPC called "xyz.123" or "xyz.456".  If the message was received over MPC "abc" the intermediary could only forward to an MPC like "abc.234", not xyz.234. So that maintains some consistency and security.
The idea behind this is that these subchannels do not have to appear in the @mpc of a message, which remains unchanged (indicating the "parent channel"). So the only difference a subchannel would make, is when pulling on these: The recipient would send a PullRequest for MPC "xyz.123" (or just "123" if the parent channel is the default.) and would know which [sub]channel to use based on PMode contract, as for any other MPC.
Different message authorization tokens can be associated with each subchannel. If none, the intermediary falls back on authorizing for the parent channel. This means that if no particular authorization is associated with each subchannel of a same parent channel, A recipient can pull on any subchannel of a parent channel for which it has the right credentials. Could be useful when subchannels only represent various priority levels for the same destination.
I would favor something like (2)...

From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Tuesday, May 13, 2008 8:24 AM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Multihop and Pull

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 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.

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