Selective pulling and failed syncronous transfers

["Pim van der Eijk" <pvde@sonnenglanz.net>]

Hello,

Could we define functionality to use "selective pulling"
based on eb3:RefToMessageId to support retrieving failed
responses in "sync" bindings?   The response MPC is
specified in the Pmode and the eb3:MessageId of the request
is specified in the request message, so all information
needed to pull the selected response message is present in a
Core v3.0 compliant request user message and Pmode.

This functionality requires the Responding MSH to store such
a response and make it available for pulling. Whether the
responding MSH does this could be configurable as an option
(e.g. pmode parameter). The configuration expresses that a
particular Two Way exchange is associated with BOTH a Sync
binding AND a fallback Push-and-Pull binding.  The response
message, when pulled, would be identical to the sync replied
response (including any reliable message sequence numbers,
message ids, security).

The implementation of a regular ebMS3 MSH would need to be
modified to do the Pull when no synchronous response is
received (when initiating, triggered by some error
condition) and to store the synchronous response so that it
can be pulled if needed (when responding). 

Two distinct situations:
-  The responding MSH successfully contructs a response user
message and attempts to send it on the backchannel, but
somehow it is lost on its way to the requesting MSH.
-  The responding MSH detects it cannot construct a
synchronous response (e.g. because the backend app that
needs to produce this response is not responding within some
interval). Would we need a special error type, a special
signal, or just send a eb3:Messaging structure without
eb3:UserMessage? 

Questions:
-  When the initiating finds out it needs to pull, how long
does it wait before pulling?  If the back-end is late, it
should not pull too soon.
-  What if there is no response on the pull, does the MSH
retry the pull, or is this an ebMS error?  If it retries,
how often does it retry and when does it give up?
-  How long does the responding MSH keep the message in the
fallback pull queue?  Messages are only pulled from it in
exceptional cases.  If the response messages are sent using
reliable messaging, sequence acknowledgments could be used
to clear any unnecessary (successfully delivered using sync)
messages.
-  v3.0 core pull with reliable messaging uses reliable pull
signals, for multihop we added non-reliable pull signals.
Which one do we need for the fallback messages?
-  ...

Pim