BTP issues list

This list is maintained by Peter Furniss, Choreology (PRF) on behalf of the OASIS Business Transactions Technical Committee

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. To update your oasis mailing list subscriptions, go to http://lists.oasis-open.org/ob/adm.pl.

List of issues, ordered by number

(the list ordered by status and category is here)

Status group is shown in headers : green=closed, one way or another, teal=deferred (closed for 1.0), purple=model draft provides an answer (it is asserted), maroon=solution proposed, fuchsia=voting, orange=depends on another issue, red=new, open

Issue 1: Format of binding addresses

Binding address format: This section status the format of the “binding address” field of a BTP address for this binding. For many bindings, this will be a URL of some kind; for other bindings it may be some other form.

in SOAP Binding, add paragraph

Binding address format: shall be a URL, of type HTTP.

In SOAP + Attachments binding, add paragraph

Binding address format: as for soap-http-1

In XML representation of Message Set, Addresses, in the informal XML , element btp:binding address, change "carrier specific URI" to "carrier specific address", and similarly in schema
Vote ended: 10 Dec 2001
Vote result: 16 yes, 1 no, 2 abstain

Issue 2: Partial sentence in BEGUN

Remove the words "this parameter" at the end of the address-as-inferior paragraph.

Remove the inferior-identifier parameter
Vote result: None opposed
Vote ended: 27 Feb 2002

Issue 3: Reference to "Full Superior"

Issue 4: Glossary is out-of-date

Issue 5: Reference to SOAP should be SOAP/HTTP

Issue 6: Informative appendices - spec or primer

Issue 7: SOAP RPC

Create outer wrappers <btp:transmission> and <btp:transmissionResponse> to surround existing <btp:messages>. Receiver can choose to send reply messages back in either wrapper, and can choose to use response message of RR carrier such as HTTP, or to send the reply as an independent one-way or RPC. Empty SOAP envelope or carrier ack to be ignored. Original sender must be prepared to receive messages either on carrier response or via listener. If reply-address is empty then reply must go in carrier response. Illegal value if carrier is non-RR.
Discussion threads in email archive:    Announcement, 7 Nov 2001    message bt-spec-oct-msg00003    Peter Furniss, 18 Dec 2001    Peter Furniss, 12 Jan 2002
Agreed solution:
SOAP RPC will not be used for the BTP-alone case (it may be used for the application-with-BTP, but that isn't the application's option, not ours). The btp:transmission element will not be present. However, to allow http responses to be used for BTP messages, rules to define the use of request/response carrier protocols are defined (the "request/response exploitation rules"). These rules are defined in general but apply to the SOAP binding. The key features are:

if a BTP message is received on a carrier request, any message to be sent by the receiver back to the sender of the request can be put in the carrier response, or can be sent on a new request in the opposite direction.

the choice of response or new request is freely up to the receiver (of the request) in the case where a real address is available as the target of the btp message and this corresponds to the sender of the original carrier request

if the target address is known but different, obviously the message must go on a new carrier request

if no target address is available (which can only be because the abstract message had a reply address, but the sender did not supply one), then the message MUST go on the carrier response.

The last rule allows the sender of one of the BTP request/response messages (e.g. any of the terminator->decider messages, REQUEST_STATUS etc) to force the btp reply to come back on the carrier response, by not sending any value for the reply-address.

The text on soap encoding, and the example of btp over SOAP are modified to have a null encodingStyle value.

This solution, including the request/response exploitation rules, is included in draft 0.9.0.4
Voted: Conference call, 16 January 2002
Vote result: unanimous consent

Issue 8: Deaf clients

Issue 9: Better explanation of Atom/Cohesion

Issue 10: Reflect message compounding in the XML Schema

The revised XML in 0.9.1.2 is aligned with the agreed solution of issue 85 : Relationship by separate container, not containment , including the related-group element.
Voted: 13 February 2002, unanimous

Issue 11: Clean up qualifiers in XML Schema

The revised XML in 0.9.1.2 defines a qualifier-type, and a separate schema containing the standard qualifiers.
Voted: 13 February 2002, unanimous

Issue 12: Minor editorials

line: 994 "All of it may may be used by" -> "All of it may be used by"
Discussion threads in email archive:    Announcement, 8 Nov 2001
Agreed solution: As submitted, with the modifications in Peter Furniss, 9 Nov 2001
Vote ended: 10 Dec 2001
Vote result: 18 yes, 1 no

Issue 13: Definition of Terminator

Issue 14: Minor editorials

-> "Remaining Inferiors" are any actors to which this endpoint…" OR "The term "remaining Inferiors" refers to any actors to which this endpoint…"
Page 70 Para 4 Sentence last:
"… there is no requirement to make the BTP state information more persistent that than the application information." -> "… there is no requirement to make the BTP state information more persistent that than the application information."
Page 121 Para 4 Sentence last - in glossary, Service:
"An actor which on receipt of an application messages may start an application operation which is appropriate.." -> "An actor, which on receipt of an application messages, may start an appropriate application operation."
Discussion threads in email archive:    Announcement, 8 Nov 2001
Agreed solution: As submitted, with the modifications in Peter Furniss, 9 Nov 2001
Vote ended: 10 Dec 2001
Vote result: 17 yes, 1 no, 1 abstain

Issue 15: Negative reply to BEGIN

change the initial description of the message to:

Sent in reply to various messages to report an error condition. The FAULT message is used on all the relationships as a general negative reply to a message.

The message has arrived when the recipient or the transaction identified by a related CONTEXT is in an inappropriate state.

In the definition of BEGIN, in the list of fault types, add

WrongState - only issued if there is a related CONTEXT, and the Superior identified by the CONTEXT is in the wrong state to enrol new Inferiors

Issue 16: Negative reply to REDIRECT

Proposed solution to issue 15 : Negative reply to BEGIN , clarifies that the FAULT message is the general negative reply message and can be used where deemed appropriate).
Vote result: None opposed
Vote ended: 27 Feb 2002

Issue 17: Use of word "peer"

Peer : The other party in a two-party relationship, as in Superior to Inferior, or Sender to Receiver

Issue 18: Response to CONTRADICTION ?

Issue 19: FAULTs from RESIGNED ?

In particular: At the end of the definition of the RESIGNED message replace

No FAULT messages are issued on receiving RESIGNED

Types of FAULT possible (sent to Superior address)

• General
• WrongState - if RESIGN has not been sent

Issue 20: Resending PREPARE

Replace quoted sentence and add a note (0.9, lines 2038, 2039)

If, for each of the Inferiors in the confirm-set, PREPARE has not been sent and PREPARED has not been received, PREPARE shall be issued to that Infeiror.

NOTE -- If PREPARE has been sent but PREPARED not yet received from an Infeiror in the confirm-set, it is an implementation option whether and when to re-send PREPARE. The Supeiror implementation may choose to re-send PREPARE if there are indications that the earlier PREPARE was not delivered.

Issue 21: Multiple Superior:Inferior relationships within a Cohesion

Issue 22: Lack of accountability reflected from D0.6 to D0.9

Issue 23: Lack of minutes to support decisions

Issue 24: The apparent complexity of model is too great.

Issue 25: Clarity needed between atomic and cohesion

Issue 26: Multiple conformance points should be defined.

(links above added - not certain if these are the correct messages - PRF)
Suggested remedy:
I believe that these discussions are under way, but not yet reflected in text.
Discussion threads in email archive:    Announcement, 8 Nov 2001
Agreed solution: Resolved by conceptual model and conformance text, including resolution to issue 87 : Conformance Level

Issue 27: Draft 0.9 is opaque, difficult to read and to understand.

Issue 28: Need for state diagrams and explanatory text

Issue 29: Redirection

Redirection is needed in BTP, at the abstract level, to support implementation approaches where a recovered actor playing Superior or Inferior roles has a different address to its original one. If a particular carrier protocol has support for redirection in a way that is sufficient, then a BTP binding to that carrier can map REDIRECT to that mechanism, and the REDIRECT message itself (as an XML or other encoding) would not appear in exchanges using that binding.

The description of "implicit messages" in the carrier protocol binding omits mentioning that a message may be implicit because it is mapped to carrier construct (although this is in fact what happens that section in the SOAP binding specifcation).

SOAP 1.1 does not have such a mechanism, and for the present bindings the REDIRECT message is used for the Superior:Inferior relationship.

The abstract message text in 0.9.2 is aligned with this, but the Redirector role description is not.

On the non-persistent relationships, communication is always initiated by one actor (in role of Initiator, Enroller, Terminator, Status requestor, Redirector) which has the address of the other (Factory, Superior, Decider, etc.), but the target of the first message will use the reply-address (or reply mechanisms of the carrier) for the reply and does not know the other's address a priori. (The messages are all effectively request/response). The REDIRECT message is therefore not used on these relationships.

However, since the actors on the non-peristent relationships can also move (often because they are also Superior or Inferior), a new FAULT/redirect can be used as a response to any of the request/response messages, carrying a list of one or more replacement addresses.

Changes

In the Redirector role desription, change the first paragraph to:

Sends a REDIRECT message to inform a Superior or Inferior that an address previously supplied for the peer (i.e. an Inferior or Superior, respectively) is no longer appropriate, and to supply a new address or set of addresses to replace the old one.

Change the parenthesis at the end off the paragraph that begins "If a Superior moves .."

(Note that the inbound message may itself be a REDIRECT message, in which case the Redirector shall use the new address in the received message as the target for the REDIRECT that it sends.)

Delete the paragraph "A Redirector may also be used to change the address of other BTP actors"

In the carrier protocol binding proforma, paragraph "Implicit messages", add "carrier-protocol mechanisms," before the first "application messages".

In the list of faults, add a row

fault-type	meaning	fault-data
Redirect	The target of the BTP message now has a different address	Set of BTP addresses, to be used instead of the address the BTP message was received on

In the fault list for REQUEST_STATUS and REQUEST_INFERIOR_STATUSES add

Redirect – if the intended target now has a different address

In the fault list for ENROL add

Redirect – if the Superior now has a different superior-address

In the fault list for BEGIN add

Redirect – if the Factory now has a different address

In the fault list for PREPARE_INFERIORS,CONFIRM_TRANSACTION,CANCEL_TRANSACTION,CANCEL_INFERIORS add

Redirect – if the Decider now has a different decider-address

Align the XML with the additions for FAULT.
Vote history: First called for email vote, ending 18th March, but call was considered unclear at conf. call 20 March and the issue will be revoted.
Vote result: 9 for, 2 opposed, 0 abstain
Vote ended: 27 Mar 2002

Issue 30: Assume that coordinators are potential sub-coordinators.

Move address-as-inferior to follow address-as-decider

Change parameter "inferior-handle" to "inferior-identifier", and change its type

In address-as-decider, change "top-level" to "top-most"

Change description for address-as-inferior to

address-as-inferior for a non-top-most transaction (a CONTEXT was related to the BEGIN), this is the address-as-inferior used in the enrolment with the Superior identified by the CONTEXT related to the BEGIN. The parameter is optional (implementor’s choice) if this is not a top-most transaction; it shall be absent if this is a top-most transaction this parameter.

Change description for transaction-identifier to the following and add the note:

transaction-identifier if this is a top-most transaction, this is an globally-unambiguous identifier for the new Decider (Composer or Coordinator). If this is not a top-most transaction, the transaction-identifier shall be the inferior-identifier used in the enrolment with the Superior identified by the CONTEXT related to the BEGIN.

Note – The “transaction-identifier” may be identical to the “superior-identifier” in the CONTEXT that is related to the BEGUNThou

Delete the word "inferior" in the penultimate line of the penultimate paragraph of the abstract message description.

Align the XML, including making transaction-identifier always present.
Voted: 13 February 2002, unanimous

Issue 31: Absense of rationale confuses normative text.

Issue 32: Italics for first use of "Business Transaction"

Issue 33: Rewording

Those parties which are confirmed create an atomic unit, within which the business transaction should have a consistent final effect.

Issue 34: Superior and Inferior

Issue 35: Superior and Inferior (2)

Issue 36: Two-phase cancel - NOT

Issue 37: Acceptable to application or participant

Issue 38: First use of "cohesion"

Issue 39: Resigning Inferior

A Superior cannot reject RESIGN. (RESIGN can only be sent before and instead of PREPARED, and can cross with PREPARE).
Vote result: None opposed
Vote ended: 27 Feb 2002

Issue 40: Sending ENROLLED

We haven't really talked about "parameters" at this stage, and this rewording seems better IMO.
Line: 593, 597
Discussion threads in email archive:    Announcement, 8 Nov 2001
Agreed solution:
Text removed by solution to issue 61 : Tables of send/receives for each role

Issue 41: ENROL/no-rsp-req

The MESSAGE/parametervalue notation is described in the "Typographic and linguistic conventions" section at the beginning of the spec.
Vote result: 13 for, 0 against
Vote ended: 19 Mar 2002

Issue 42: Cohesive Superior

Issue 43: REQUEST_STATUS and STATUS coupling

Issue 44: Decider and other terms

Issue 45: Compound addresses

OK, so we mention “compound” on page 25, but it’s not obvious that this is possible from the previous paragraphs. Wherever we do describe compounding, I’d like to add: “It is important for the sender of a compound address to realise that inconsistencies may occur if different recipients decide to use different elements of the compound address and no strong consistency protocol exists between the end-points in the address.”
Line: 980 - 1010 approx
Discussion threads in email archive:    Announcement, 8 Nov 2001
Vote result: Resolved by conceptual model text; No comment on default vote ended 11 April

Issue 46: Ordering of A+B

The form A&B is used to refer to a combination where message B is sent in relation to A (“relation” is asymmetric). The form A+B is used to refer to A and B bundled together - the transmission of the bundle "A+B" is semantically identical to the transmission of A followed by the transmission of B.

Issue 47: Handle and Identifier

Issue 48: completion of enrollment

Issue 49: type of Handle

Issue 50: Default parameter values

Do we not also need to be consistent on the names: hyphenated or not.
Line: 1343, 1419
Discussion threads in email archive:    Announcement, 8 Nov 2001    Tony Fletcher, 29 Jan 2002    Tony Fletcher, 8 Feb 2002    Doug Bunting, 27 Feb 2002    pp Alex Ceponkus, 4 Mar 2002
Agreed solution:
In the body of the text, abstract message definitions and the XML

change "reply-requested" to "response-requested" for all uses of the parameter

"response-requested" has a default of "false" in all cases

"report-hazard" has no default value specified. The parameter is mandatory in the XML.

hyphenate all parameter names consistently
Vote result: 13 for, 1 against, 1 abstain
Vote ended: 27 Feb 2002

Issue 51: RESIGN and PREPARED

RESIGN may be sent at any time prior to the sending of a PREPARED or CANCELLED message (which cannot then be sent). RESIGN may be sent in response to a PREPARE message.

Issue 52: Forms of PREPARE

PREPARE_INFERIORS is sent by Terminators to Composers

There is no equivalent sent by Terminators to Coordinators - the only way a Coordinator is induced to send PREPARE to its Inferiors is by CONFIRM_TRANSACTION
Vote result: unanimous consent
Voted: Conference call, 30 January

Issue 53: will or may contradict ?

Issue 54: hazard forms

level

mixed/possible

Add paragraph explaining

level indicates, with value “mixed” that a mixed condition has definitely occurred; or, with value “possible” that it is unable to determine whether a mixed condition has occurred or not.

In xml for hazard, add attribute

level="mixed|possible"

Issue 55: CONFIRM_ONE_PHASE and PREPARE

and PREPARE has not been sent to it

Issue 56: State table text

Issue 57: XML Schema applicable to more than SOAP

delete the word "XML" in the first line of the binding profoma section

change the BTP message representation in the proforma text to:

BTP message representation: This section will define how BTP messages are represented. For many bindings, the BTP message syntax will be as specified in the XML schema defined in this document, and the normal string encoding of that XML will be used.

delete "for SOAP bindings" from heading "XML Representation for SOAP bindings"
Voted: Conference call, 16 January 2002
Vote result: unanimous consent

Issue 58: Minor editorials

Issue 59: Interposition description needed

ML: what happened to the interposition section I sent weeks ago? I would like to see it in the document. (Now accessible as Word document (50 Kb) )

PF: It seemed the text was more of the explanation and guidance kind than a necessary part of the spec. per se, so I left it to be included in the primer - though obviously the level of detail isn't exactly first-level introduction. In the ultra-tight specification that is 0.9, interposition is kind of alluded to rather than detailed.

ML: I don't think this is sufficient. Even if it's just the part of the text I sent that describes what is expected from an interposition implementation (e.g., changing "transaction context") this is important. Do I need to raise this as an issue, or can you just put this back?
Discussion threads in email archive:    Announcement, 12 Nov 2001
Vote result: Resolved by conceptual model text; No comment on default vote ended 11 April

Issue 60: address-as-role or role address

The names should be aligned or the difference justified in the text.
Discussion threads in email archive:    Announcement, 19 Nov 2001    Tony Fletcher, 13 Feb 2002
Proposed solution A:
Use the form "address-as-<role>" consistently throughout the text including the XML.
Proposed solution B:
Use the form "<role>-address" consistently throughout the text including the XML.

First vote ended: 27 Feb 2002 - proposal was what is now solution A
First vote result: 6 for, 9 against
Vote result: 4 for A, 9 for B : B approved
Second Vote ended: 19 Mar 2002

Issue 61: Tables of send/receives for each role

Issue 62: Names of the relationships

The names "Control" relationship and "Outcome" relationship are suggested.
Discussion threads in email archive:    Announcement, 19 Nov 2001    Peter Furniss, 12 Jan 2002
Agreed solution:
Use the names "outcome" and "control" as headings for the sets of roles and messages, introducing them in the relationships section:

In section on relationships, add the following to the paragraph after the list of events:

The various particular relationships can be grouped as the "control" relationships - primarily Terminator:Decider, but also Initiator:Factory; and the "outcome" relationships - primarily Superior:Inferior, but also Enroller:Superior.

At the beginning of the following paragraph, change "primary" to "groups of".

In the headings "Roles involved in ..." change "Superior:Inferior" to "outcome", and "Terminator:Decider" to "control", and make "relationship" plural.

In the abstract message list, add headings (for the separate messages):

Messages not restricted to outcome or control relationships
Messages used in outcome relationships
Messages used in control relationships

These changes are included in draft 0.9.0.4
Voted: Conference call, 16 January 2002
Vote result: unanimous consent

Issue 63: Clarify the terminology around actors, roles and relationships

Issue 64: can inferior know type of superior ?

Issue 65: participant as immediate inferior of composer ?

Issue 66: Event diagram for termination protocol

Draft 0.9.5.1 contains three additional diagrams to those in 0.9.5, with explanatory paragraphs. The new figure 15 shows a termination sequence for a composer, figure 17 shows a termination sequence including a contradiction. The new figure 14 shows the state changes, and the triggering events for a Sub-coordinator and Sub-composer.
Vote details: William Z Pope, 23 Apr 2002 (bt-main)
Vote result (second vote): 14 for, none opposed

Issue 67: "Hazard" from autonomous decision ?

Delete the parenthesized text in the first paragraph

Add an explanatory note

Note - If the Inferior makes its own autonomous decision then it signals that decision with CONFIRMED or CANCELLED and waits to receive a confirmatory CONFIRM or CANCEL, or a CONTRADICTION if the autonomous decision by the Inferior was the opposite of that made by the Superior.

Issue 68: (sub)coordinators, (sub)composers with no inferiors

Issue 69: prepared subcomposer with unprepared inferiors ?

Issue 70: Confirm-set evolution

Issue 71: Messages for Terminator

No further change
Vote result: None opposed
Vote ended: 27 Feb 2002

Issue 72: Scope of Context

Issue 73: ACID relaxation in overview

Issue 74: WrongState from CONFIRM_ONE_PHASE

Should be "sent to this Inferior"
Discussion threads in email archive:    Announcement, 27 Nov 2001
Agreed solution:
Change as suggested - "sent to this Inferior"
Vote result: unanimous consent
Voted: Conference call, 30 January

Issue 75: Ensure that all the participants of a BT are enrolled.

Issue 76: Need for explanatory material

Issue 77: Inferior identification

It would helpful to have a compound construct "inferior identification" which is a choice between (inferior address, inferior identification) and (inferior handle).
Discussion threads in email archive:    Announcement, 30 Nov 2001    Peter Furniss, 25 Jan 2002
See discussion under: issue 78 : Addresses used for identification
Dependent issue: issue 47 : Handle and Identifier
Agreed solution:
The proposed solution for issue 78 : Addresses used for identification makes the inferior-handle unnecessary.

Delete the "inferior handle" as a field of ENROLLED.

In the "inferior-list" parameters of various messages, make it a list of inferior-identifiers, not inferior-handles

In the last paragraph on the "CONTEXT_REPLY & ENROL & application message (& PREPARED)" group, change reference to "inferior-handle on ENROLLED" to "inferior-identifier on ENROL"

Change other references to "inferior-handle" to "inferior-identification" (and adjust unambiguity desriptions appropriately)

Align the XML
Vote result: unanimous consent
Voted: Conference call, 30 January

Issue 78: Addresses used for identification

There is no protocol need for this to be a set of addresses - it could just be one, with the rule that a single address matches a set of addresses if it is the same as any member of the set. There is some text on this already, but it needs checking.
Discussion threads in email archive:    Announcement, 30 Nov 2001    Sanjay Dalal, 15 Jan 2002    Pyounguk Cho, 15 Jan 2002    Peter Furniss, 25 Jan 2002    Mark Little, 30 Jan 2002    Doug Bunting, 30 Jan 2002    Peter Furniss, 2 Feb 2002    Mark Little, 1 Feb 2002
Proposed solution: This text has been revised after discussion of the issue on 30 January

Summary: Make Identifier globally unambiguous, rather only unambiguous within the scope of the related addresses. Syntactically make it a URI.

Drop the disambiguating addresses from messages, and modify the text for the corresponding identifier

In abstract messages and the XML for the messages:

Change the text introducing the identifiers in the abstract messages (i.e. in CONTEXT, ENROL, BEGUN) to state that they are globally unambiguous (for all other messages, identifiers are defined by reference to one of these three)

CONTEXT_REPLY - delete superior-address

STATUS - delete responders-address.

RESIGN, PREPARED, CANCELLED, CONFIRMED, HAZARD, INFERIOR_STATE - delete address-as-inferior