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: inline

From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Tuesday, May 20, 2008 2:20 PM
To: Durand, Jacques R.; 'Sander Fieten'; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Multihop and Pull

If we view MPC as the Pull equivalent of a URL for Push, then preserving its value could be just as (un)informative, and since the URLs are rewritten in every hop, the same may be true for MPCs. No strong opinions here, and there may be cases where the MPC names are informative.   
<JD> a major difference for "transparency" is that @mpc is part of headers, but the URL(s) are not so can be changed without altering the message.. 
Incidentally the @mpc attribute is a User Message attribute in the ebMS 3.0 XSD.  Shouldn't it be an attribute on eb:Messaging?  If we want to support bundling, an MSH can only pull a complete ebMS message, not selectively some UserMessage in that message.  If MPC is used for priorities, then all user messages in a bundle must have the same priority. 
<JD> The main reason why MPCs are assigned to [User] message units and not to ebMS messages as a whole (eb:Messaging) is that the notion of MEP is defined at User message unit level (i.e. for a single User message unit)(see 2.2.2), and is orthogonal to any bundling. So a PullRequest is targeting User Message units over a particular MPC. What is being queued for pulling, is in fact message units.
But I see your point. I think we have a problem with eb:signals: if @mpc must be added somewhere it should probably be on signal Message units (Receipts, errors...) so that these can be pulled independently , on some MPC.
As for making @mpc an attribute of eb:Messaging, I wouldn't go as far.
 We have yet to specify the bundling in a multi-hop context. Also we have not yet deciced that all User Messages bundled together should be for the same MPC.
E.g. we might want to support "bulk" sending  across the I-cloud to some Hub, where the bundle will be broken down at this Hub for detail pulling by many endpoint MSHs (based on different MPCs). (Conversely, could a Hub getting many messages for the same destination - or that it knows will be routed to teh same other Hub - perform bundling ?
So to sum up, I think if there is an errata to consider it is to add @mpc for eb:signal messages.
Furthermore, when an unadressable MSH pushes a message which generates an error that (for some reason) is not delivered on the back channel, the MSH may want to pull that error from the next MSH. What MPC does it use to pull any such errors from?

From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
Sent: 17 May 2008 04:47
To: Sander Fieten; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Multihop and Pull

Sander summarized well the subchannel proposal: I think it just makes the MPC change a bit cleaner (although more constrained), while enabling the use case Pim talks about.
The concern with an "unrestrained MPC re-assignment" is, if an intermediary can re-assign a message to an MPC that has no relationship at all with @mpc in the message, then there is no assurance anymore (no meaning) attached to this attribute, for a Sender.
That would mean the @mpc semantics will vary depending on the topology:
- for point-to-point transfer (no intermediary) the original @mpc is quite meaninglul. There is some clear contract with a pulling Receiver, and some authorization credential associated.
- for multi-hop transfer, original @mpc becomes meaningless in terms of guarantee for the Sender that the message will remain associated with expected authorization credentials on Receiver side.  And if you say that only what is in @mpc counts when authorizing the pull, even if the PullRequest pulls on a different MPC, that becomes quite contrived. (do we allow messages with different @mpc in the same re-assigned MPC? What authorization data should be used by a PullRequest for an MPC? etc)
The subchannel solution allows for the following additional use case:
- a Pulling endpoint MSH (X) pulls messages from a single Hub, and is delivering to several Parties on its application side. It is just one endpoint MSH among several that pull from this Hub.
- Sending MSHs only specify @mpc based on the type of Service used in the header (several To/Parties can provide the same Service) so messages to these different parties still use same @mpc if for the same Service.
- Therefore, the endpoint MSH X is using same authorization data to pull from this MPC.
- Yet some To/Parties must have higher priorities than others, i.e. get their messages sooner.
- The Hub offers as a service to assign sub-channels based on To/Parties and their priority level.
- Then MSH X can pull selectively on these sub-channels, yet uses same authorization credentials that were agreed upon between partners, associated with the common @mpc value set from the beginning.
The "dot" notation I suggest is just an example. We could use a more URI-compliant notation, e.g. fragment identifiers.
That way, the MPC as a resource never formally change: it is only extended on the way with a property fragment that can be used for later selective pulling. In the case of a default MPC (no @mpc) adding the "default MPC" URI is just a convention that does not complcate the reassignment. We could decide that a Puller only needs to specify the fragment in that case.

From: Sander Fieten [mailto:sander@fieten-it.com]
Sent: Friday, May 16, 2008 12:43 PM
To: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Multihop and Pull


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.


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

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. 


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

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

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]