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
