BTP maintenance issues list

This file last updated 13:33 15 Sep 2003 (UTC)

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

Members of the committee should comment on these issues by sending to the bt main list, with a subject line that begins "Issue - <issueid> - " (e.g. "Issue - maint-4 - ") or is a reply to such a message. (The script that finds and links relevant emails from the archive looks for this string, after discarding Re: etc.). Members of the committee can submit new issues by sending to the issues list maintainer, Peter Furniss, Choreology, who will assign a number, add an entry and announce the issue on the bt main list.

The list is uploaded to the OASIS BTP TC pages on a regular basis, if there have been changes, and will be the most recent document titled btp_maintenance_issues_list.html in the "Issues" folder in the BTP TC document list. Since the uri of an uploaded document includes the document number assigned in the upload process, the uri for the current official TC document version is unpredictable. However, the editor's working copy of the list is also maintained on this constant url - at times of rapid change, this may be more up-to-date.

Issue numbers are maint-1, maint-2 etc to distinguish them from the original, pre-1.0 issues, and the extensions issues (ex-1, ex-2 etc). (The extensions list will be the most recent Issues document with the title "btp_extra_issues_list.html" - again the editor's working copy has a constant uri.)

All issues, in order

IssueIDTitleStatusDate addedLast changed
Issue maint-1HAZARD after receiving CANCELnew17 Oct 2002 
Issue maint-2CONFIRMED element should be confirm-receivednew17 Oct 2002 
Issue maint-3CONFIRM_ONE_PHASE against autonomous confirmnew17 Oct 2002 
Issue maint-4reply to cancel_inferiorsopen16 Jul 200316 Jul 2003
Issue maint-5Superior identifier needed before sending INFERIOR_STATE/unknownopen16 Jul 200316 Jul 2003
Issue maint-6"confirming" status should include auto-confirmingopen16 Jul 200316 Jul 2003
Issue maint-7Differences between xml schema and informal message descriptionopen16 Jul 200316 Jul 2003
Issue maint-8Allow late enrollmentsopen16 Jul 200316 Jul 2003
Issue maint-9Qualifiers for each inferior on CONFIRM_TRANSACTIONopen16 Jul 200316 Jul 2003

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 maint-1: HAZARD after receiving CANCEL

Status: new
Category: minor technical
Date added: 17 Oct 2002
Submitter: Peter Furniss, Choreology
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

Target document: Committee Specification 1.0 (3 June 2002)
Links:    Announcement, 17 Oct 2002
Changes:

Issue maint-2: CONFIRMED element should be confirm-received

Status: new
Category: minor technical
Date added: 17 Oct 2002
Submitter: Mark Potts, Talking Blocks, Alex Ceponkus
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

Target document:
Committee Specification 1.0 (3 June 2002) and Core schema (3 June 2002)
Links:    Announcement, 17 Oct 2002
Changes:


Issue maint-3: CONFIRM_ONE_PHASE against autonomous confirm

Status: new
Category: minor technical
Date added: 17 Oct 2002
Submitter: Peter Furniss, Choreology
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.

Target document: Committee Specification 1.0 (3 June 2002)
Links:    Announcement, 17 Oct 2002
Changes:


Issue maint-4: reply to cancel_inferiors

Status: open
Date added: 16 Jul 2003
Submitter: Roddy Herries
Description: If cancel_inferiors expects an inferior_statuses in return then it isnít indicated in the 1.0 spec
Changes: 16 Jul 2003 - new issue

Issue maint-5: Superior identifier needed before sending INFERIOR_STATE/unknown

Status: open
Date added: 16 Jul 2003
Submitter: Peter Furniss
Description: INFERIOR_STATE/unknown is sent when a message is received for an inferior that does not exist and for which no information is held. For example

The problem is that the INFERIOR_STATE/unknown needs to carry the superior identifier so the message will get delivered to the approriate state machine. But the superior identifier is not on the PREPARE (the superior address is, at least logically). The inferior has no record of what superior was involved with the deceased inferior node.

The only right answer would seem to be to add the superior identifier as a parameter to the superior to inferior messages that can get a reply of INFERIOR_STATE/unknown (PREPARE, CONFIRM, CANCEL, CONFIRM_ONE_PHASE).

Bad alternative: drop the superior identifier in the INFERIOR_STATE/unknown case. The message will get back to the sending system, but it has no easy way of knowing which of its superiors this involves. This special case would require the superior system to keep an inferior:superior lookup for all inferiors it was involved with. (and if made general, would mean we didn't need the superior id on any of the up tree messages.
Changes: 16 Jul 2003 - new issue


Issue maint-6: "confirming" status should include auto-confirming

Status: open
Date added: 16 Jul 2003
Submitter: Peter Furniss
Reference: clause 7.6.4
Description: definition of status value "confirming" doesn't mention autoconfirm decision - it should do. (by comparison with cancelling)
Changes: 16 Jul 2003 - new issue

Issue maint-7: Differences between xml schema and informal message description

Status: open
Date added: 16 Jul 2003
Submitter: Fabrice Matrat
Reference: page 140
Description: The informal message set beginning page 140 contains differences compared to the xml schema

Response requested is not mandatory (minOccurs=0 and specified default) for enrol/resign/inferior-state/superior-state in the xml schema but there is no indication that they are optional in the informal message set.

decider, inferior address and transaction identifier is not mandatory for begun in the xml schema but not in the informal message set.

In the xml schema "fault" doesnít contain a fault text.
Changes: 16 Jul 2003 - new issue


Issue maint-8: Allow late enrollments

Status: open
Date added: 16 Jul 2003
Submitter: Peter Furniss
Description: Late enrollment - enrolling new inferiors after others have been told to prepare - is already allowed under control of the superior application, using prepare_inferiors. It should also be allowed when the superior is sending PREPARE as a result of a CONFIRM_TRANSACTION. This does not violate checking integrity providing there are other inferiors that have not yet prepared.

Allowing late enrollment makes it possible to have a first, enrolled inferior (A) that hands over its work to another inferior (B) when A receives PREPARE. B is enrolled (and typically would spontaneously prepare), and then A either sends PREPARED or RESIGN. Sending RESIGN makes the behaviour essentially equivalent to the pre-completion synchronization behaviour of other protocols, but without requiring a separate kind of enrollment or knowledge by the superior of what is going on.

The changes needed in the spec would be to allow "use" of a CONTEXT for new enrollments after a CONTEXT-REPLY(completed) has been sent.
Changes: 16 Jul 2003 - new issue


Issue maint-9: Qualifiers for each inferior on CONFIRM_TRANSACTION

Status: open
Date added: 16 Jul 2003
Submitter: Peter Furniss
Description: When application qualifiers are to be sent on CONFIRM, it is very likely that different inferiors will need to have different qualifiers (e.g. a stock quote is made with the confirmation/cancellation determined by BTP, but the quote is bi-directional, and qualifiers on CONFIRM have to say confirm(buy) or confirm(sell)).

Controlling this via CONFIRM_TRANSACTION requires some way of passing qualifiers and identifying which inferiors they are to be sent to. This could be done by changing the inferiors-list, or having a separte list of qualifiers-for-inferiors. If the former is done, it will be necessary to allow inferiors-list to be present even for an atom.
Changes: 16 Jul 2003 - new issue


This file last updated 13:33 15 Sep 2003 (UTC)