When the ultimate receiver wants to pull messages it first has to
establish a RM-sequence
for sending the PullRequest signal. When acting according to the Core
spec the CreateSequence
will contain an offer to establish a RM-sequence for sending messages
to the
ultimate receiver (step 2).
<JD> Reading Core V3 again, I believe that the obligation to use RM for
PullRequest only exists for the "Reliable One-way / Pull MEP (section
8.3.2)". But in our new multi-hop context, we have something new: this
is still a One-way, but Pushed half-way and Pulled half way, something
not described in the core spec. Something we could call: "One-way /
Push-then-Pulled". For this, Core V3 does not say anything in Section
8.3 or in appendix B.2.3: it is not your regular "One-way / Pull MEP".
In particular, the destination of the PullRequest (from endpoint B to
last Intermediary) is not supposed to have any RM capability. So I
consider we are relieved from the necessity to send PullRequest
"reliably".
In that case, your steps #1 and #2 may not be necessary.
In fact, the reason to use RM for PullRequest (for reliable One-way /
Pull in Core V3) was to provide a way for the pulled side to resend the
User Message, for each PullRequest duplicate received. This mechanism
does not exist in our multi-hop topology: the only endpoint able to do
resending of the (exact) same UserMessage, is the initial sender A. And
as soon as the last intermediary has sent the UserMessage (over the
backchannel of a PullRequest for this MPC) then if the message is lost
there is no use for PullRequest resending: only the original sender will
do the resending, which can then be relayed by a NEW PullRequest later
on.