RE: [bt-spec] BTP Issue 96 : Reply address on SUPERIOR, INFERIOR_STATUS

[Peter Furniss <peter.furniss@choreology.com>]

 

BTP Issue 96 : Reply address on SUPERIOR, INFERIOR_STATUS

Category: minor technical
Submitter: Pyounguk Cho, IONA (drafted PRF)
Description:
Reply address should be added to the parameter list when reply requested = true

The *_STATUS messages can be sent when the receiving side has no knowledge of the location or identity of the partner. If a reply is needed (it will be the /unknown), the responder needs to know where to send it.

---

 

I've been holding back on this one until some of the other issues were sorted out. It's slightly trickier than first appears.

 

The statement in the description of the issue is true - a *_STATUS message can arrive when the receiver has no knowledge of the transaction (typically it presume-aborted, possibly quite early, or has completed and been forgotten).  In such a case, the receiver obviously has no knowledge of where the other side is, so needs to be told on the message where to send the reply.

 

However, not just the *_STATUS but any of the messages sent between Superior and Inferior are liable to arrive when the target is unknown, and none of them carry the address of the sender (since the addresses were exchanged on the CONTEXT and ENROL messages). The reply message is normally the appropriate *_STATUS/unknown (it's CANCELLED if the default-is-cancel was used - because otherwise a contradiction could be undetected)

 

At least at abstract level therefore, *all* the Superior:Inferior messages need a a reply-address. Unlike the messages on CONTEXT and ENROL, this need not be a set  (all that is needed is an immediate reply - there's no need for the receiver of a message for an unknown superior or inferior to try repeatedly to send a reply back)

 

At concrete level with a request/response binding, the reply address can be implicit, and the reply message sent back on the carrier response. With the request/response exploitation rules, this follows automatically if the reply-address field is absent.

 

However, the specification of the request/response rules currently uses the presence of a "reply-address" parameter to distinguish which messages are paired and which not. And the Superior/Inferior messages should normally (i.e. if the branch is known about) go to (one of) the recorded address(es) of the peer.

 

So, in outline, the solution would be

 

add a reply-address parameter to all the superior-inferior messages and make distinct lists of request-reply message pairs, using that as the criterion in the request-response exploitation rules. Add text explaining that the reply-address on the sup-inf messages is only used if the target is unknown

 

An alternative would be to make this parameter the "senders-address", distinguishing it from the reply-address. (though the effect would be the same)

 

I think I prefer the alternative at the moment, but this doesn't look like a good one to have alternative solutions for.

 

Peter

------------------------------------------
Peter Furniss
Technical Director, Choreology Ltd
web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX