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

Well, no one commented, so I've written up the sender-address solution. That keeps the request/response rules nearly unchanged.

There is likely to be some editorial overlap with some of the other issues under discussion - 100, but I think that is only editorial.

Delete the last paragraph in the section Abstract Messages, Request/response pairs and insert:

Between Superior and Inferior the address of the peer is normally known (from the "superior-address" on an earlier CONTEXT or the "inferior-address" on a received ENROL). However, in some cases a message will be received for a Superior or Inferior that is not known - the state information no longer exists. This is not an exceptional condition but occurs when one side has either not created or has removed its persistent state in accordance with the procedures, but a message has got lost in a failure, and the peer still has state information. The response to a message for an unknown (and logically non-existent) Superior is SUPERIOR_STATE/unknown, for an unknown Inferior it is INFERIOR_STATE/unknown. However, since the intended target is unknown, there is no information to locate the peer, which sent the undeliverable message. To enable the receiver to reply with the appropriate *_STATE/unknown, all the messages between Superior and Inferior have a "senders-address" parameter. If a FAULT message is to be sent in response to message which (as an abstract message) has a "senders-address" parameter, the FAULT message is sent to that address.

Note - Both reply-address and senders-address may be absent when the carrier protocol itself has a request/response pattern. In these cases, the reply or sender address is implicitly that of the sender of the request (and thus the destination of a response)

Add a "sender-address" parameter, with type BTP address to the following messages: ENROLLED, RESIGN, RESIGNED, PREPARE, PREPARED, CONFIRM, CONFIRMED, CANCEL, CANCELLED, CONFIRM_ONE_PHASE, HAZARD, CONTRADICTION, SUPERIOR_STATE, INFERIOR_STATE. The explanation for the parameter is:

sender-address the address from which the <message> is sent. This is an address of the <Superior|Inferior>.

substituting appropriately.

For these messages, where there is a FAULTs paragraph, change the text to "... (sent to "sender-address")

In the XML definitions add to the messages listed above: <code> <btp:sender-address> ...address... </btp:sender-address>

In Carrier Protocol Bindings, Bindings for request/response carrier protocols, add at the end of the third paragraph:

These rules also allow the receiver of a message between Superior and Inferior (in either direction) on a carrier protocol request to send any reply message on the carrier response - the "sender-address" field is implicitly considered to be that of the sender of the carrier request.

In the following Request/response exploitation rules, change the fourth paragraph to:

Within the outcome relationship, apart from ENROL, there is no "reply-address", and the parties normally know each other's "superior-address" and "inferior-address". However, these messages have a "sender-address", which is used when the receiver does not have knowledge of the peer. In this case, the "sender-address" is treated as the "reply-address" of the other messages - if the field is absent in a message on a carrier request, the "sender-address" is implicitly that of the request sender. Any message for the peer (including the three messages mentioned, FAULT but also any other valid message in the Superior:Inferior relationship) may be sent on the carrier response. Apart from this, both sides are permitted to treat the carrier request/response exchanges as opportunities for sending messages to the appropriate destination.

Add a new rule:

d) A BTP actor that has received, on a carrier protocol request, one or more BTP messages or related groups that, as abstract messages, have a "sender-address" parameter but no "reply-address" was supplied and does not have knowledge of the peer address, must bundle the responding BTP message and groups in a btp:messages element and transmit this element on the carrier protocol response to the request that carried the BTP request. If the actor does have knowledge of the peer address it may send one or messages for the peer in the carrier protocol response, regardless of whether the binding address of the peer matches the address of the carrier protocol requestor.

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

bt-spec message