Pull MEP

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)