BTP extensions and additions issues list

This file last updated 15:29 14 Sep 2004 (UTC)

This list covers matters that have been proposed or considered for inclusion in a future edition of the Business Transaction Protocol specification. Initially, the list contained issues resolved as "deferred" in the progression of the BTP Committee Specification 1.0 - these entered this list as "open". Members of the committee may raise issues for inclusion in this list. Errors and problems with the 1.0 specification are dealt with in the maintenance issues 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 - ex-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_extra_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 ex-1, ex-2 etc to distinguish them from the original, pre-1.0 issues, and the maintenance issues (maint-1, maint-2 etc). (The maintenance list will be the most recent Issues document with the title "btp_maint_issues_list.html" - again the editor's working copy has a constant uri.)

All issues, in order

The colour of the issue title is determined by the status: green=resolved (10 issues).

Status category is shown in headers : green=closed, one way or another, maroon=solution proposed, fuchsia=voting, orange=depends on another issue, red=new, open

Issue ex-1: Identifiers and addresses in received messages

1. Keep things as they are, including a list of addresses in each "initial" messages. Any changes to the list of addresses are handled using the REDIRECT message, either as a response to a message or pro-actively sent by the actor in question. Least changes required but mixes additional semantics with messages such as CONTEXT, BEGIN and ENROL. This also requires all of the query messages either include an optional address list or come from previously identified actors.
2. Separate the name to address binding from existing messages, putting DIRECT (or some such) into a class with REDIRECT and recognizing them as special. Some changes to the specification required but simplifies many of the existing messages and centralizes discussion of these bindings. Initial message bundle between two actors MUST include a DIRECT message (unless option 3 below is adopted).
3. As part of transport bindings, recognize particular URI schemes as usable for both names and locations. The particular example is HTTP. Actors receiving messages from new senders would implicitly bind such names to an address comprised of the identical location and the binding on which the message was received. Second part is necessary because a location such as those in the HTTP scheme carries no information about the binding used to reach that location, it isn't enough to form a usable address. Unfortunately, application / actor layers above the transport are commonly unaware of the binding used by received messages.

Closed without change.
Links:    Announcement, 30 Jan 2002
Changes: 26 Jan 2004 - fields: Status, Resolution

Issue ex-2: Is entity identity modification to be allowed within BTP.

RENAME/RENAMED

whose sole responsibility is similar to REDIRECT but replaces the identifier an actor was known about with another.
Resolution: Agreed at 3 february 2004 con call

Closed with no change (see Mark Little, 3 Feb 2004)
Links:    Announcement, 2 Feb 2002        Mark Little, 2 Feb 2002        Mark Little, 6 Feb 2002     Mark Little, 3 Feb 2004
Changes: 3 Feb 2004 - fields: Status, Resolution, Agreed resolution, Links;    12 May 2004 - fields: Agreed solution, Vote ended, Vote result

Issue ex-3: CONTEXT used only with application msgs, not with BEGIN, BEGUN

2. Add what would have been context payload into the begin/begun messages for begin/begun exchanges.

This would give the following benefits:

1. Context message semantics are much cleaner (i.e. we only see it if we are an application).

2. Simply message exchange for the creation of transactions.

Original number: Issue 103
Resolution: Proposed in Peter Furniss, 5 May 2004, agreed at the 11 May 2004 conference call

Details of the solution covering this issue and issue ex-7 are in WSfriendly_bindings.prf.2004-03-30.doc (document details).
Links:    Announcement, 3 Feb 2002        JIM WEBBER, 2 Feb 2002        Peter Furniss, 13 Mar 2002     Mark Little, 3 Feb 2004     Proposed solution (document details)     see also issue ex-7     Proposed resolution (Peter Furniss, 5 May 2004)
Changes: 3 Feb 2004 - fields: Links;    5 May 2004 - fields: Links, Status, Proposed resolution;    12 May 2004 - fields: Status, Proposed solution, Proposed resolution, Resolution

Issue ex-4: Qualifier to allow automatic completion of all-cancelled cohesions

There will be a new standard qualifier with with bi-valued (yes/no) parameter, to be sent on BEGIN, PREPARE_INFERIORS or CANCEL_INFERIORS to have the suggested effect.

Mark Little will provide text.
Links:    Mark Little, 20 Feb 2002        Announcement, 22 Feb 2002     Mark Little, 3 Feb 2004     Peter Furniss, 1 Mar 2004     Mark Little, 1 Mar 2004
Changes: 3 Feb 2004 - fields: Status, Resolution, Links;    1 Mar 2004 - fields: Links

Issue ex-5: SOAP/HTTP binding should include HTTP/SSL

Change the definition of binding address format for "soap-http-1" to

Binding address format: shall be a URL, of scheme http or https.

Issue ex-6: CONFIRM_ONE_PHASE after PREPARE

All subsequent cases and collisions are already dealt with (or at least are liable to occur when PREPARE is not sent explicitly).
Target document: Committee Specification 1.0 (3 June 2002)
Resolution: Agreed at 20 January 2004 conference call

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".
Links:    Announcement, 17 Oct 2002
Changes: 26 Jan 2004 - fields: Status, Suggested solution, Resolution

Issue ex-7: Web-service friendly bindings

In particular, there should be a binding for the request/response oriented Control protocol that can represented as WSDL operations, facilitating the implementation of simple of control clients.

This would require omission or reduction of the "wrapper" constructs around the messages. Moving the CONTEXT (or its content) inside the BEGIN and BEGUN messages would facilitate this. (see issue ex-3 : CONTEXT used only with application msgs, not with BEGIN, BEGUN )
Resolution: Proposed in Peter Furniss, 5 May 2004 (which mistakenly references ex-3, corrected in Peter Furniss, 11 May 2004, agreed at the 11 May 2004 conference call

Details of the solution are in WSfriendly_bindings.prf.2004-03-30.doc (document details) - see also BTP-Control-Relationship-Abstract-WSDL-2004_03_29.wsdl (document details) and 2004-03-30.btp-1-0-core.xsd (document details).
Links: Alex Ceponkus, 20 Jan 2004     Peter Furniss, 17 Feb 2004     Announcement, 1 Mar 2004     Peter Furniss, 30 Mar 2004     Main text of proposed solution (document details)     Proposed WSDL for control relationship (document details)     Proposed core schema (document details)     Proposed resolution (Peter Furniss, 5 May 2004)     Peter Furniss, 11 May 2004
Changes: 1 Mar 2004 - new issue;    1 Mar 2004 - fields: Links;    15 Mar 2004 - fields: Links;    5 May 2004 - fields: Links, Status, Proposed resolution;    6 May 2004 - fields: Links;    11 May 2004 - fields: Links;    12 May 2004 - fields: Status, Proposed resolution, Resolution

Issue ex-8: BTP-aware web-services need to declare their BTP-awareness

There should be a means at least for application interfaces defined using WSDL to state that they require a BTP context and will return a BTP context-reply.
Resolution: proposed in Peter Furniss, 22 Jun 2004, agreed by Web ballot (ended 13 Jul 2004)

Defer this issue. Resolution will not be included in the BTP 1.1 specification.

The area is clearly in flux, and I wouldn't like to try to define a "universal" statement, usable in any of these, without some hand-holding from experts in the particular policy declaration mechanisms. This is our last open issue on BTP 1.1, and it could easily take a long time and a lot of going round the loop to sort this out. We could perhaps treat it as an independent item, as part of the continuing maintenance activity.

See also email William Z Pope, 22 Jun 2004
Links: Announcement, 15 Mar 2004     Peter Furniss, 15 Mar 2004     Proposed resolution (Peter Furniss, 22 Jun 2004)
Changes: 15 Mar 2004 - new issue;    15 Mar 2004 - fields: Links;    27 Aug 2004 - fields: Status, Resolution, Links

Issue ex-9: participant identification in context-reply

There are already several ways that this can be done with BTP, but they are all rather application-specific. At present, one could:

• set the inferior name qualifier on the enrol to a field that is present in the application response (such as the quote number)
• put the inferior identifier as a field of the application message
• send the ENROL message in the header of the application message (using the one-shotting optimisation - if the carrier supports it, and it is appropriate for the configuration).

None of these could readily be supported by generic software in the way a propagated context could be in the opposite direction. There should be some general way.
Submitter's proposal: A possibility would be to allow an inferior identifier to be placed in the CONTEXT-REPLY, which would have similar semantics to having an CONTEXT-REPLY&ENROL&application message related group as far as association was concerned.

Alternatively, the presence of an inferior name qualifier on a CONTEXT-REPLY could be defined as having the similar meaning.

Note that both of these are essentially using CONTEXT-REPLY as just the standardised carrier of this information, rather than invent another message (REVERSE-CONTEXT ?) just for this purpose.
Resolution: Proposed in Peter Furniss, 5 May 2004, decided at conf call 25 May 2005

Add an optional to CONTEXT-REPLY to contain an inferior identifier. Define an additional related group CONTEXT_REPLY & Application Message, whose meaning is defined as:

This related group applies only if the CONTEXT_REPLY message contains an inferior identifier value. In this case the transmission of the Application Message (and application effects implied by its transmission) has been associated with the Inferior whose identifier is in the CONTEXT_REPLY and the effects will be subject to the outcome delivered to that Inferior.

The rest of the text for the related group will be supplied by the editor and ratified in the next draft.
Links: Announcement, 23 Mar 2004     Proposed resolution (Peter Furniss, 5 May 2004)
Changes: 23 Mar 2004 - new issue;    5 May 2004 - fields: Links, Status, Proposed resolution;    6 May 2004 - fields: Links;    25 May 2004 - fields: Status, Proposed resolution, Resolution

Issue ex-10: acknowledgements for LRT

Any protocol message that will (in theory, subject to implementation level administrative or deployment overrides) be resent indefinitely until a state-moving message is received “in reply”, should be capable of receiving a receipt-acknowledgement, whose reception can be interpreted to mean: I would prefer you not to resend the message I have just received. I will reply in my own good time, and I estimate that this time will be no less than X seconds away.

Absent such acks, it is very difficult to obtain the appropriate balance between fault-tolerance and good network citizenship. Customers don’t like excess network traffic.

The recoverable nature of all retriable conversations ensures that the use of a receipt-ack will not terminate the conversation prematurely or wrong-headedly.

The SUPERIOR_STATUS/prepared-received message might be used as a model or basis for the syntax of such a message.
Resolution: Proposed in Peter Furniss, 5 May 2004, decided at conf call 25 May 2005

Add the new status values to INFERIOR_STATE and SUPERIOR_STATE:

INFERIOR_STATE/prepare-received
INFERIOR_STATE/confirm-received
INFERIOR_STATE/cancel-received

SUPERIOR_STATE/confirmed-received
SUPERIOR_STATE/cancelled-received

Add a new standard qualifier "expected time till state change" that can be sent on any message to give an indication of how long the sender thinks it might be before it does something interesting.

The message and the qualifier are informational - they do not cause state change, they do not forbid the sender from changing state much earlier, they do not commit the sender to changing state at the time stated and they do not change the persistence/recovery requirementsimplied by BTP.

Add the new values to the state tables to show when they can be sent and received.
Links: Announcement, 23 Mar 2004     Peter Furniss, 23 Mar 2004     Proposed resolution (Peter Furniss, 5 May 2004)
Changes: 23 Mar 2004 - new issue;    6 May 2004 - fields: Status, Proposed resolution, Links;    25 May 2004 - fields: Status, Proposed resolution, Resolution

This file last updated 15:29 14 Sep 2004 (UTC)