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.
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)...
Line 998-1000 of ebMS 3.0, Part 1, Core Spec states:
Line 1048-1050 goes on to state that:
"A PullRequest signal message always indicates in its header (see Section 126.96.36.199) 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.