[bt-spec] Deferred BTP Issue 107 : Reply to CONFIRM_TRANSACTION if allis ok

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

This issue has been added to the BTP issue list as a deferred issue, to be considered for a future edition of the spec.

BTP Issue 107 : Reply to CONFIRM_TRANSACTION if all is ok

Submitter: Peter Furniss, Choreology
Arising from: issue 50 : Default parameter values 
Category: editorial
Description:
The abstract message definition says does not say what happens after CONFIRM_TRANSACTION if report_hazard is true and nothing goes wrong, though it does detail all the other cases.

There isn't any equivalent text for CANCEL_TRANSACTION.
Suggested solution:
Add in the definition of CONFIRM_TRANSACTION

> If "report-hazard" was "true", TRANSACTION_CONFIRMED shall be sent to the "reply-address" after CONFIRMED has been received from each Inferior in the confirm-set and CANCELLED or RESIGN from each and any Inferior not in the confirm-set.
---------------------
Add in the definition of CANCEL_TRANSACTION

If "report-hazard" was "false", a TRANSACTION_CANCELLED message shall be sent to the "reply-address".

If "report-hazard" was "true" and any HAZARD or CONFIRMED message was received, an INFERIOR_STATUSES reporting the status for all Inferiors shall be sent to the "reply-address".

If "report-hazard" was "true", TRANSACTION_CANCELLED shall be sent to the "reply-address" after CANCELLED or RESIGN has been received from each Inferior.

---

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 a description of the issue to Peter Furniss peter.furniss@choreology.com. Please propose a category (technical, minor technical, editorial, minor editorial) and whether the issue proposed for the current edition or a future edition.