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


Pim,

I do agree with you that reassigning a message to another MPC requires the MUST on line 1046 of the core spec to be changed, otherwise reassigning without modifying the message header will lead to a violation of the core spec. I think there are now two proposals for this change:

(1) [Pim] Change the MUST to a SHOULD. This allows intermediaries to reassign message to an abitrary MPC;

(2) [Jacques] Introduce the concept of subchannels and only allow to reassingments to subchannels.

Option (1) I think is the most easy change as it only requires one word to be changed or could be done in part two of the spec by relaxing the requirement of the core spec. Option (2) will require some more work in describing subchannels and their usage. Should this be done in the core spec or as an extension to the MPC defintions in part two?  I would prefer option (2) as an extension to the core spec because I think the restriction on reassigning messages to subchannels is clearer. 

Another thing is that on line 795 of the core spec it is stated that "A Sending MSH MUST be able to determine whether a submitted message should be pulled or pushed, and to which Message Partition Channel (MPC) it must be assigned". In the multi-hop situation one of the requirement is just the opposite, that the sending MSH does not need to know whether the message will be pulled by or pushed to the utlimate receiver. I'm not sure if this requires a change to the core spec or can be done by relaxing this requirment in part two in case of a multi-hop situation.

Sander


On 15 mei 2008, at 23:12, Sander Fieten wrote:
Pim,

I think that Jacques option 2 is a more specific version of your proposal by allowing the intermediary to reassign message to another MPC with a restriction on the MPC's URI. Although I agrre with you that for message posted to the default MPC this does not make much sense, I can imagine that for non default MPC it is clearer to keep the original MPC available. 

Regards
Sander

On 15 mei 2008, at 23:01, Pim van der Eijk wrote:
Hello Jacques,
 
My proposal is not to change the message (for transparency reasons and for signature preservation as you point out), so whatever @mpc is put in the message (if any) will remain there until delivery.  But relaxing the MUST to SHOULD would allow an intermediary to reassign a message sent to mpc abc to a different channel xyz, based on inspection of header data or other configuration. Intermediaries also may forward (in push mode) message to different URLs (ignoring the URL the original sender sent the message to, as it were).  MPC authentication is to the intermediary that is pulled from, not to the true sender. Whatever MPC the intermediary assigns messages to is an agreement between that intermediary and the pulling business partner. It does not need to be standardized.
 
Assume an intermediary that provides mailboxes to hundreds or thousands of small businesses. Messages are sent to these businesses using different eb3:To/PartyId[@type=Type]['Value'] in messages that may or may not have @mpc attribute value. An intermediary could by convention map them to channels based on To/PartyId/mpc or some similar convention. If only subchannels are allowed, then we would need to define channels http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/defaultMPC.duns:12345678 etc. up to http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/defaultMPC.duns:97654321 for messages that don't have a value for @mpc. In the case of multihop, a default MPC (for pull) makes as little sense as a default URL (for push).
 
Pim

From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
Sent: 13 May 2008 23:46
To: Pim van der Eijk; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Multihop and Pull

Pim:
 
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)...
 
Jacques


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

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
 






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