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.
Jacques
From: Sander Fieten
[mailto:]
Sent: Friday, May 16, 2008 12:43
PM
To:
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:]
Sent: 13 May 2008 23:46
To: Pim van der Eijk;
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:]
Sent: Tuesday, May 13, 2008 8:24 AM
To:
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
