There are two perspectives
on the Pull MEP, that we need to choose from:
Option 1. Pulling is only intended
to accommodate MSH connectivity restrictions,
e.g. lack of static IP
address, firewall restrictions, intermittent availability, etc.
In such cases, the pulling
is an MSH-level mode of operation, which could
remain opaque to the
application layer (or user layer). E.g., a sender party
would submit a message to an
MSH, and not even be aware whether this message will be
pushed or pulled (the way
this party interacts with its MSH is an implementation issue.)
COnsequence: When this mode
is on between MSH1-MSH2, MSH1 will pull all messages
intended to it from MSH2,
regardless of the party that submitted.
No need to provide a
"partyId" parameter.
Option 2. Pulling is also intended
to accommodate back-end communication,
i.e. may be controlled by
parties who submit messages for sending, or who want to
decide whether their
received messages would be pulled or not.
COnsequence: Pulling may be
done at PartyId granularity. The MEP mode is decided
between two parties (by
agreement, which of course needs be consistent with connectivity
constraints). MSH2 may queue
messages intended for party A to pull, while pushing
messages intended for party
B. (A and B being served by same MSH1)