Pim's multihop use case

["Jacques R. Durand" <JDurand@us.fujitsu.com>]

 We need to decide how to handle this specific multi-hop situation (a Use Case originated by Pim), which could mean deciding which sub-case is most important :

 

Use Case:

A party is sending messages to a large number of recipients over the I-Cloud. These recipients are supposed to pull these messages from their edge-intermediary (the forwarding pattern used by this intermediary is either "push-pull" or "pull-pull".) Each recipient must pull its own messages. However the sending party does not want to be concerned with several MPCs, one for each recipient, and is sending all messages over the same MPC. The last intermediary alone is aware of which message should be forwarded to which recipient - i.e. must be able to distinguish pulling recipients and return only a message intended to its recipient.

Two solutions are considered:

Solution (1): the "sub-channels" solution described in 1.6.4 of latest posted V30 draft (4/15).

Solution (2): An Intermediary MAY be able to associate several "access points" with an MPC. Each access point has its own authorization data. When "multiple access points" are supported for an MPC, the Intermediary MUST be able: (a) to associate each received user message over this MPC with a particular access point, based on header information. (b) when receiving a PullRequest for the MPC , to determine which access point is concerned based on authorization credentials, and to only return messages matching this access point to the requestor.

Advantage of Solution 1: works well in cases when there is no authorization data associated with PullRequest (see sub-case B), as it works independently whether authorization is used or not.

Advantage of Solution 2: On the endpoint, does not require knowledge of any "sub-channel": only authorization info is needed to pull messages. The PullRequest is still targeting the same MPC. Seems better for sub-case (A).

Sub-case (A): This sub-case applies when all recipients are un-related and yet associated with the same Intermediary (Hub): Each recipient must be prevented from pulling messages of other recipients. Each pull signal is therfore authorized differently from one recipient to the other. All PullRequest signals must be authorized.

Sub-case (B): This sub-case applies when all recipients belong to the same entity (say various departments of a same company). Pull authorization is not considered worth the overhead, as it is not critical if a department accidentally pulls a message for another department. However each pulling must be selective for efficiency reason - each dept pulling its own messages.

 

Jacques