RE: [bt-spec] BTP Issue 104 : RESIGN, disruption and CONFIRM_ONE_PHASE

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

 The "suggested solution" is included in the 0.9.1.3 state tables, and in the hyperlinked version on the choreology website.

 

I propose the "suggested solution" be adopted.

 

Peter

BTP Issue 104 : RESIGN, disruption and CONFIRM_ONE_PHASE

Category: minor technical
Submitter: Peter Furniss, Choreology
Description:
The 0.9 state tables omit the possibility of a failure (disruption) at the Superior after receiving RESIGN/rsp-req causing a reversion to the active (B1) state. This inevitably can occur, since there is a time window between the arrival of the message and the implementation doing anything about it.

This would not matter (it could be treated as just the loss of the RESIGN message), except that the same state (C1) is also entered if CONFIRM_ONE_PHASE crosses with RESIGN/rsp-req. The 0.9 state tables require that RESIGNED is still sent by the superior, and the CONFIRM_ONE_PHASE is effectively ignored by the Inferior.

However, the requirement to send RESIGNED in this case is quite unnecessary It would be much simpler to say that RESIGN/rsp-req is "answered" by receipt of CONFIRM_ONE_PHASE and vice versa. (In fact this means the whole transaction has evaporated and there weren't any changes applied anywhere.)
Suggested solution:
Allow transition C1:disruption -> B1

Change S1:receive RESIGN/rsp-req to -> Z

Change c1:receive CONFIRM_ONE_PHASE to -> z

---

 h