This file last updated 16:18 26 Oct 2004 (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.)
| IssueID | Title | Status | In spec | Date added | Last changed |
|---|---|---|---|---|---|
| Issue maint-14 | Minor state table corrections | resolved | 10 Sep 2004 | 20 Oct 2004 | |
| Issue maint-15 | InvalidSuperior/InvalidInferior Faults used inappropriately | resolved | 14 Sep 2004 | 20 Oct 2004 | |
| Issue maint-16 | Impossible fault destinations | resolved | 14 Sep 2004 | 20 Oct 2004 | |
| Issue maint-17 | Superior identifier on other messages to inferior | resolved | 7 Oct 2004 | 26 Oct 2004 |
| IssueID | Title | Status | In spec | Date added | Last changed | Revisitable |
|---|---|---|---|---|---|---|
| Issue maint-1 | HAZARD after receiving CANCEL | resolved | 17 Oct 2002 | 26 Nov 2003 | ||
| Issue maint-2 | CONFIRMED element should be confirm-received | resolved | 17 Oct 2002 | 26 Nov 2003 | ||
| Issue maint-3 | CONFIRM_ONE_PHASE against autonomous confirm | resolved | 17 Oct 2002 | 26 Nov 2003 | ||
| Issue maint-4 | reply to cancel_inferiors | resolved | 16 Jul 2003 | 26 Nov 2003 | ||
| Issue maint-5 | Superior identifier needed before sending INFERIOR_STATE/unknown | resolved | 16 Jul 2003 | 7 Oct 2004 | ||
| Issue maint-6 | "confirming" status should include auto-confirming | resolved | 16 Jul 2003 | 26 Nov 2003 | ||
| Issue maint-7 | Differences between xml schema and informal message description | resolved | 16 Jul 2003 | 11 May 2004 | ||
| Issue maint-8 | Allow late enrollments | resolved | 16 Jul 2003 | 6 May 2004 | ||
| Issue maint-9 | Qualifiers for each inferior on CONFIRM_TRANSACTION | resolved | 16 Jul 2003 | 26 Jan 2004 | ||
| Issue maint-10 | Duplicate items in lists | resolved | 26 Jan 2004 | 3 Feb 2004 | ||
| Issue maint-11 | Allow repeat CANCELLED | resolved | 22 Mar 2004 | 25 May 2004 | ||
| Issue maint-12 | Address priority attribute | resolved | 11 May 2004 | 25 May 2004 | ||
| Issue maint-13 | CONFIRM_ONE_PHASE report-hazard default | resolved | 11 May 2004 | 27 Aug 2004 | ||
| Issue maint-14 | Minor state table corrections | resolved | 10 Sep 2004 | 20 Oct 2004 | ||
| Issue maint-15 | InvalidSuperior/InvalidInferior Faults used inappropriately | resolved | 14 Sep 2004 | 20 Oct 2004 | ||
| Issue maint-16 | Impossible fault destinations | resolved | 14 Sep 2004 | 20 Oct 2004 | ||
| Issue maint-17 | Superior identifier on other messages to inferior | resolved | 7 Oct 2004 | 26 Oct 2004 |
The colour of the issue title is determined by the status: green=resolved (17 issues).
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
Allow an inferior to send HAZARD after receiving
CANCEL - change the inferior state table to have "p1" in "detect problem/n1"
Links: Announcement, 17 Oct 2002
Changes: 25 Nov 2003 - fields: Status, Proposed resolution;
26 Nov 2003 - fields: Status, Proposed resolution, Resolution
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)
Resolution: see msg Peter Furniss, 14 Oct 2003, agreed at 25 Nov 2003 conf call
Change the schema and specification XML to align
with the main text, making the element "confirm-received" not "confirmed-received".
Links: Announcement, 17 Oct 2002
Changes: 25 Nov 2003 - fields: Status, Proposed resolution;
26 Nov 2003 - fields: Status, Proposed resolution, Resolution
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)
Resolution: see msg Peter Furniss, 14 Oct 2003, agreed at 25 Nov 2003 conf call
Add a transition to "S1" in the "decide to
confirm one-phase / H1" cell of the superior table
Links: Announcement, 17 Oct 2002
Changes: 25 Nov 2003 - fields: Status, Proposed resolution;
26 Nov 2003 - fields: Status, Proposed resolution, Resolution
Add the following paragraph after the explanation of the parameters of CANCEL_INFERIORS
For all Inferiors identified in the inferiors-list parameter, from which neither CANCELLED or RESIGNED has been received, the Decider shall issue CANCEL. It will reply to the Terminator, using the "reply-address" on the CANCEL_INFERIORS message, sending an INFERIOR_STATUSES message giving the status of the Inferiors identified on the inferiors-list parameter.
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.
Resolution: proposed in msg Peter Furniss, 14 Oct 2003, approved at 16 December 2003 meeting
Add superior-identifier as a parameter on PREPARE, CONFIRM, CANCEL and CONFIRM_ONE_PHASE, in
the tables of parameters, the explanations and the XML. For consistency with the superior-to-inferior
messages, this should be the first parameter.
Links: Peter Furniss, 14 Sep 2004
see issue maint-17
Changes: 16 Jul 2003 - new issue;
25 Nov 2003 - fields: Status, Proposed resolution;
16 Dec 2003 - fields: Status, Proposed resolution, Resolution;
14 Sep 2004 - fields: Status, Proposed resolution, Links;
7 Oct 2004 - fields: Status, Proposed resolution, Links
in the table in 7.6.4, change the "Meaning from Inferior" entry for Confirming to:
CONFIRM has been received or an auto-confirm has been decided (CONFIRMED/auto may or may not have been sent); CONFIRMED/response has not been sent
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.
Resolution: Proposed in Peter Furniss, 5 May 2004, decided at conf call 11 May 2004
Accept the changes in the text he submitted in Alex Ceponkus, 16 Mar 2004, which are included in draft 1.0.9.1 (document details)
Move the schema's out of the text document and have them as separate ascii files.
The separate files should be directly and specifically referenced from the text and
regarded as logically part of it.
Links: Peter Furniss, 6 Jan 2004
Alex Ceponkus, 16 Mar 2004
Proposed resolution (Peter Furniss, 5 May 2004)
Changes: 16 Jul 2003 - new issue;
6 Jan 2004 - fields: Links;
17 Mar 2004 - fields: Links;
5 May 2004 - fields: Links, Status, Proposed resolution;
6 May 2004 - fields: Links;
11 May 2004 - fields: Status, Proposed resolution, Resolution
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.
Resolution: Approved in principle at 16 December 2003, text to be supplied by editor, Peter Furniss
Editor's text in Working draft 1.0.9.1 (document details)
Changes: 16 Jul 2003 - new issue;
16 Dec 2003 - fields: Status, Resolution;
6 May 2004 - fields: Resolution
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.
Discussion: From 16 December 2003 meeting:
The change should apply to cancel_inferiors and prepare_inferiors as well.
A structure of ( (qualifier, list of identifiers) , ... ) could be more efficient than ( (identifier, qualifier), (identifer , qualifier) , ...)
Peter to provide text
Resolution: proposed in maint9_alternative_solution.doc (document details), agreed at 6 January 2004 meeting (document details)
Links: Peter Furniss, 6 Jan 2004
Peter Furniss, 6 Jan 2004
Doug Bunting, 6 Jan 2004
Peter Furniss, 7 Jan 2004
Doug Bunting, 8 Jan 2004
Changes: 16 Jul 2003 - new issue;
16 Dec 2003 - fields: Discussion;
6 Jan 2004 - fields: Links;
8 Jan 2004 - fields: Links;
12 Jan 2004 - fields: Links;
21 Jan 2004 - fields: Status, Proposed resolution, Resolution;
26 Jan 2004 - fields: Resolution
What is required to happen if a list (of inferiors or qualifiers) contains duplicate entries ?
Is the receiver required to catch the fault ?
Suggested solution: The sender is obviously behaving incorrectly (i.e. it is a programming error).
However, since the error is harmless, confined to the control protocol and
fairly peculiar, it is unreasonable to require all implementations to check
every received list. However, it is an error and implementations should be
allowed to fault it.
A general statement should be added that the behaviour when duplicate entries are present
is undefined - implementations are free to ignore the duplicate or return a FAULT/general.
Resolution: Agreed at 3 february 2004 con call
As suggested:
Add a general statement that the behaviour when duplicate entries are present
is undefined - implementations are free to ignore the duplicate or return a FAULT/general.
Links: Doug Bunting, 8 Jan 2004 (see item 4)
Changes: 26 Jan 2004 - new issue;
3 Feb 2004 - fields: Status, Resolution
Add additional state z2, entered on sending CANCELLED where this currently transits to z. If an inbound message is received, transit to a new query state (y3), which is exited by resending CANCELLED, reverting to z2. Disruption (loss of volatile information) should cause a transition to existing z. (Thus the current behaviour can be treated as a disruption I.)
Links: Peter Furniss, 23 Mar 2004
Announcement, 23 Mar 2004
Proposed resolution (Peter Furniss, 5 May 2004)
Changes: 22 Mar 2004 - new issue;
5 May 2004 - fields: Links, Status, Proposed resolution;
6 May 2004 - fields: Links;
25 May 2004 - fields: Status, Proposed resolution, Submitter's proposal, Resolution
priority="...value..."? attribute to btp:some-address element on line 3452 (of BTP 1.0 PDF.)
priority? attribute to superior-address elemment in CONTEXT abstract xml. line 3496
priority? attribute to inferior-address elemment in ENROL abstract xml. line 3600
priority? attribute to new-address element in REDIRECT abstract xml. line 3819
priority? attribute to decider-address element in BEGUN abstract xml. line 3844
priority? attribute to inferior-address element in BEGUN abstract xml. line 3847
<attribute name="priority" type="positiveInteger"
use="optional" default="1"/>
to address type in schema (line 57?)
The submitter's proposal is accepted.
Links: Announcement, 11 May 2004
Changes: 11 May 2004 - new issue;
25 May 2004 - fields: Status, Proposed resolution, Submitter's proposal (renamed from Submitter's solution), Resolution, Links
CONFIRM_ONE_PHASE report-hazard has a default, and is not consistent
with report-hazard found on CONFIRM_TRANSACTION and CANCEL_TRANSACTION.
Submitter's solution:
minOccurs="0" default="false"
from report-hazard element in confirm-one-phase (line 346 of schema.)
Remove the "report-hazard" parameter from the CONFIRM_ONE_PHASE message. Actual edits to be made by the editor.
In version 1.0.9.1 (and previous) of the specification the CONFIRM_ONE_PHASE message may have a "report-hazard" parameter. This is incorrect. The CONFIRM_ONE_PHASE message should not have a "report-hazard" parameter.
See also justification in 2004-06-14-MaintIssue13.txt (document details)
Links: Announcement, 11 May 2004
Peter Furniss, 25 May 2004
Proposed resolution (Peter Furniss, 14 Jun 2004)
Sazi Temel, 15 Jun 2004
Changes: 11 May 2004 - new issue;
25 May 2004 - fields: Links;
26 May 2004 - fields: Links;
15 Jun 2004 - fields: Links, Status, Proposed resolution;
27 Aug 2004 - fields: Status, Proposed resolution, Resolution
However, for most cases the detailed text and the state tables specify that INFERIOR_STATE/unknown or SUPERIOR_STATE/unknown (as appropriate) is sent, or, for the last message of the Outcome exchange, the incoming message should be ignored.
Similarly, REQUEST_STATUS allows a reply of FAULT/Unknown-transaction,
which would seem to be an unecessary synonym for STATUS/unknown.
Resolution: Approved in Web ballot (ended 14 Oct 2004)
Remove the statements that allow unnecessary Fault values.
Leave Fault/InvalidInferior as a response where the inferior is not valid for the transaction
in question (e.g. on up-tree messages)
Links: Announcement, 14 Sep 2004
Peter Furniss, 14 Sep 2004
Changes: 14 Sep 2004 - new issue;
14 Sep 2004 - fields: Links;
20 Oct 2004 - fields: Status, Resolution (renamed from Proposed resolution)
For various messages of the control relationships, the existing text states that BTP Faults are sent "decider address" or various other addresses that are not in fact fields of the received message. This occurs with messages that are responses to some other message (e.g. TRANSACTION_CONFIRMED as a reply to CONFIRM_TRANSACTION).
For PREPARE_INFERIORS and CANCEL_INFERIORS, the text says the reply is sent to "Superior-address", which is not a
field of PREPARE_INFERIORS.
Submitter's proposal: Messages that do not have a reply address should not generate
BTP Fault messages at all (obviously they could cause SOAP faults).
Remove the Fault lists from STATUS, TRANSACTION_CONFIRMED, TRANSACTION_CANCELLED and INFERIOR_STATUSES
For PREPARE_INFERIORS, CANCEL_INFERIORS, change the destination of the Fault to "reply-address"
Resolution: Approved in Web ballot (ended 14 Oct 2004)
Links: Announcement, 14 Sep 2004
Peter Furniss, 14 Sep 2004
Changes: 14 Sep 2004 - new issue;
28 Sep 2004 - fields: Status, Proposed resolution;
7 Oct 2004 - fields: Links;
20 Oct 2004 - fields: Status, Resolution (renamed from Proposed resolution)
The resolution of Issue maint-5 adds the superior-identifier as a field of the the superior-to-inferior messages that can potentially cause a returning INFERIOR_STATE/unknown (PREPARE, CONFIRM, CANCEL, CONFIRM_ONE_PHASE) but not to the other messages travelling that way (ENROLLED, RESIGNED, CONTRADICTION, SUPERIOR_STATE).
This seems mildly odd - it would seem
to be a bit cleaner to have the superior-identifier on all the down-tree messages.
Resolution: Proposed in submitter's proposal, decided by Web ballot (ended 25 Oct 2004)
Add superior-identifier as a field of ENROLLED, RESIGNED, CONTRADICTION and SUPERIOR_STATE
Vote announcement: Web ballot (ends 25 Oct 2004)
Links: Announcement, 7 Oct 2004
Changes: 7 Oct 2004 - new issue;
7 Oct 2004 - fields: Links;
20 Oct 2004 - fields: Status, Vote announcement, Proposed resolution;
26 Oct 2004 - fields: Status, Proposed resolution, Submitter's proposal, Resolution
This file last updated 16:18 26 Oct 2004 (UTC)