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

[BTP issues maintainer <peter.furniss@choreology.com>]

This issue has been added to the BTP issue list

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

---

To comment on this issue, please follow-up to this announcement on the bt-spec@lists.oasis-open.org (replying to this message should automatically send your message to that list).

The current draft, with line numbers is available in pdf format and word format.

To add a new issue, please email to Peter Furniss peter.furniss@choreology.com. It helps if you propose a category (technical, minor technical, editorial, minor editorial).