[bt-spec] BTP extensions and additions issue x.6 : CONFIRM_ONE_PHASEafter PREPARE

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

This issue has been added to the BTP extensions and additions issues list

BTP extensions and additions issue x.6 : CONFIRM_ONE_PHASE after PREPARE

Category: minor technical
Submitter: Peter Furniss, Choreology
Target document: Committee Specification 1.0 (3 June 2002)
Description:
The state tables do not allow the sending of CONFIRM_ONE_PHASE after sending PREPARE, unless
PREPARED has been received. There is no reason why a node should not send out PREPARE's to multiple Inferiors, then
determine, as a result of messages received (e.g. RESIGNs from all other Inferiors) that only one Inferior
will be confirmed. If it had not sent PREPARE to that one inferior (perhaps because the application protocol
carried the equivalent end-of-data semantic), it would be allowed to switch that inferior to CONFIRM_ONE_PHASE, so
why not allow it if PREPARE has been sent.

All subsequent cases and collisions are already dealt with (or at least are liable to occur when PREPARE is not sent explicitly).
Suggested solution:
In the Superior table, allow a transition to S1 from "decide to confirm one-phase / D1".

In the Inferior table, allow a transition to s1 from "receive CONFIRM_ONE_PHASE / d1".

---

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

To add a new issue, please email a description of the issue to Peter Furniss peter.furniss@choreology.com. Please identify whether the issue is considered to be an error or omission in the current specification (for the maintenance list) or an addition or enhancement ( for the enhancements list)