BTP maintenance issues list

This list covers real and perceived errors and omissions in the Business Transaction Protocol Committee Specification 1.0, as distinct from suggested addtitions and enhancements (which go in the extensions and enhancements list).

Members of the committee should comment on these issues by sending to the bt specification list, preferably as a follow-up to the original announcement of the issue (to keep the thread connection). Members of the committee can submit new issues by sending to Peter Furniss, Choreology who will assign a number, add an entry and announce the issue on the bt specification list.

Procedures for the addition and discussion of issues on this list may be changed shortly

Issue numbers are m.1, m.2 etc to distinguish them from the original, pre-1.0 issues, and the extensions issues (x.1, x.2 etc).

To update your oasis mailing list subscriptions, go to http://lists.oasis-open.org/ob/adm.pl.

List of issues, ordered by number

NumberNameCategorystatus
Issue m.1HAZARD after receiving CANCELminor technicalnew
Issue m.2CONFIRMED element should be confirm-receivedminor technicalnew
Issue m.3CONFIRM_ONE_PHASE against autonomous confirmminor technicalnew

Status category is shown in headers : green=closed, one way or another, teal=deferred (closed for 1.0 - transferred to extensions and additions list), maroon=solution proposed, fuchsia=voting, orange=depends on another issue, red=new, open


Issue m.1: HAZARD after receiving CANCEL

Status: new
Date added: 17 Oct 2002
Category: minor technical
Submitter: Peter Furniss, Choreology
Target document:
Committee Specification 1.0 (3 June 2002)
Description:
The inferior state table does not allow HAZARD to be sent after receiving CANCEL (state n1), although it is possible for a problem to occur in the underlying resource or subtree after CANCEL has come in.
Suggested solution:
Fix will be to add "p1" as the transition for "detect problem" in state "n1".
Original report: Peter Furniss, 8 Jul 2002

Discussion threads in email archive:    Announcement, 17 Oct 2002

Issue m.2: CONFIRMED element should be confirm-received

Status: new
Date added: 17 Oct 2002
Category: minor technical
Submitter: Mark Potts, Talking Blocks, Alex Ceponkus
Target document:
Committee Specification 1.0 (3 June 2002) and Core schema (3 June 2002)
Description:
The XML definitions for the CONFIRMED message have an element "confirmed-received". According to the specification, 7.7.8 CONFIRMED (p. 90), it should be "confirm-received".

The error occurs in both the schema and specification (section 10.2.13, line 3700)
Original reports: Mark Potts, 9 Jul 2002 Alex Ceponkus, 10 Jul 2002

Discussion threads in email archive:    Announcement, 17 Oct 2002


Issue m.3: CONFIRM_ONE_PHASE against autonomous confirm

Status: new
Date added: 17 Oct 2002
Category: minor technical
Submitter: Peter Furniss, Choreology
Target document:
Committee Specification 1.0 (3 June 2002)
Description:
The Superior state table do not allow CONFIRM_ONE_PHASE to be issued after an autonomously-sent CONFIRMED has been received. (The Inferior does allow CONFIRM_ONE_PHASE to arrive after the CONFIRMED has been sent, since they may cross on the wire).

This imposes restrictions on an implementation, as it may be difficult to avoid the messages crossing inside the superior communications mechanisms.
Suggested solution:
Allow a transition to S1 in the decide to confirm one-phase / H1 cell.
Discussion threads in email archive:    Announcement, 17 Oct 2002


This file last updated 14:52 17 Oct 2002 (UTC)