BTP issues list - prior to Committee Spec 1.0

This is the issues list used in the development of BTP Committee Specification 1.0, from the starting point of draft 0.9. Since the Committee Specification 1.0 has now been completed, this list is only of historic interest. The issues with final status "deferred" have been transferred to the extensions and additions issues list.

List of issues, ordered by number

(the list ordered by status and category is here)

NumberNameCategorystatus
Issue 1Format of binding addressesminor technicalchange agreed
Issue 2Partial sentence in BEGUNeditorialchange agreed
Issue 3Reference to "Full Superior"minor editorialchange agreed
Issue 4Glossary is out-of-dateeditorialchange agreed
Issue 5Reference to SOAP should be SOAP/HTTPminor technicalchange agreed
Issue 6Informative appendices - spec or primereditorialresolved
Issue 7SOAP RPCtechnicalchange agreed
Issue 8Deaf clientstechnicalchange agreed
Issue 9Better explanation of Atom/Cohesioneditorialresolved
Issue 10Reflect message compounding in the XML Schemaminor technicalchange agreed
Issue 11Clean up qualifiers in XML Schemaminor technicalchange agreed
Issue 12Minor editorialsminor editorialchange agreed
Issue 13Definition of Terminatoreditorialresolved
Issue 14Minor editorialsminor editorialchange agreed
Issue 15Negative reply to BEGINminor technicalchange agreed
Issue 16Negative reply to REDIRECTminor technicalchange agreed
Issue 17Use of word "peer"editorialchange agreed
Issue 18Response to CONTRADICTION ?minor technicalresolved
Issue 19FAULTs from RESIGNED ?minor technicalchange agreed
Issue 20Resending PREPAREminor technicalchange agreed
Issue 21Multiple Superior:Inferior relationships within a Cohesionminor technicalresolved
Issue 22Lack of accountability reflected from D0.6 to D0.9editorialwithdrawn
Issue 23Lack of minutes to support decisionseditorialwithdrawn
Issue 24The apparent complexity of model is too great.technicalresolved
Issue 25Clarity needed between atomic and cohesiontechnicalresolved
Issue 26Multiple conformance points should be defined.technicalresolved
Issue 27Draft 0.9 is opaque, difficult to read and to understand.editorialresolved
Issue 28Need for state diagrams and explanatory texteditorialresolved
Issue 29Redirectiontechnicalchange agreed
Issue 30Assume that coordinators are potential sub-coordinators.technicalchange agreed
Issue 31Absense of rationale confuses normative text.editorialwithdrawn
Issue 32Italics for first use of "Business Transaction"minor editorialresolved
Issue 33Rewordingeditorialchange agreed
Issue 34Superior and Inferioreditorialresolved
Issue 35Superior and Inferior (2)editorialresolved
Issue 36Two-phase cancel - NOTeditorialresolved
Issue 37Acceptable to application or participanteditorialresolved
Issue 38First use of "cohesion"editorialresolved
Issue 39Resigning Inferiorminor technicalresolved
Issue 40Sending ENROLLEDeditorialresolved
Issue 41ENROL/no-rsp-reqeditorialchange agreed
Issue 42Cohesive Superioreditorialresolved
Issue 43REQUEST_STATUS and STATUS couplingeditorialresolved
Issue 44Decider and other termseditorialresolved
Issue 45Compound addresseseditorialresolved
Issue 46Ordering of A+Bminor technicalchange agreed
Issue 47Handle and Identifiertechnicalresolved
Issue 48completion of enrollmentminor technicalresolved
Issue 49type of Handletechnicalresolved
Issue 50Default parameter valuestechnicalchange agreed
Issue 51RESIGN and PREPAREDeditorialchange agreed
Issue 52Forms of PREPAREminor technicalresolved
Issue 53will or may contradict ?minor technicalresolved
Issue 54hazard formsminor technicalchange agreed
Issue 55CONFIRM_ONE_PHASE and PREPAREminor technicalchange agreed
Issue 56State table texteditorialresolved
Issue 57XML Schema applicable to more than SOAPeditorialchange agreed
Issue 58Minor editorialsminor editorialchange agreed
Issue 59Interposition description needededitorialresolved
Issue 60address-as-role or role addressminor technicalchange agreed
Issue 61Tables of send/receives for each roleeditorialchange agreed
Issue 62Names of the relationshipsminor technicalchange agreed
Issue 63Clarify the terminology around actors, roles and relationshipseditorialresolved
Issue 64can inferior know type of superior ?minor technicalresolved
Issue 65participant as immediate inferior of composer ?minor technicalresolved
Issue 66Event diagram for termination protocoleditorialchange agreed
Issue 67"Hazard" from autonomous decision ?minor technicalchange agreed
Issue 68(sub)coordinators, (sub)composers with no inferiorsminor technicalresolved
Issue 69prepared subcomposer with unprepared inferiors ?minor technicalresolved
Issue 70Confirm-set evolutionminor technicalresolved
Issue 71Messages for Terminatoreditorialresolved
Issue 72Scope of Contexttechnicalresolved
Issue 73ACID relaxation in overvieweditorialresolved
Issue 74WrongState from CONFIRM_ONE_PHASEeditorialchange agreed
Issue 75Ensure that all the participants of a BT are enrolled.technicalresolved
Issue 76Need for explanatory materialeditorialresolved
Issue 77Inferior identificationminor technicalchange agreed
Issue 78Addresses used for identificationminor technicalchange agreed
Issue 79Normalising the message settechnicalchange agreed
Issue 80CONTEXT_REPLY unnecessary for CONTEXT/cohesionminor technicalchange agreed
Issue 81Resending ENROLminor technicalchange agreed
Issue 82ENROL related to application messageminor technicalchange agreed
Issue 83BTP message related to *part of* application messageminor technicalchange agreed
Issue 84What determines one-shot is usedminor technicalchange agreed
Issue 85Relationship by separate container, not containmentminor technicalchange agreed
Issue 86Reply address on CONTEXT, target address on CONTEXT_REPLYminor technicalchange agreed
Issue 87Conformance Leveltechnicalchange agreed
Issue 88Cohesion vs Atomictechnicalresolved
Issue 89J2EE Inter operability - JMS short circuittechnicalresolved
Issue 90Process Flows and TRX switch formatstechnicalwithdrawn
Issue 91Global state visibility - Cohesionstechnicalwithdrawn
Issue 92Benchmarking Metricstechnicalwithdrawn
Issue 93The Spec leveleditorialwithdrawn
Issue 94Target addressing information may be absentminor technicalchange agreed
Issue 95fault data for WrongState FAULTminor technicalchange agreed
Issue 96Reply address on SUPERIOR, INFERIOR_STATUSminor technicalchange agreed
Issue 97Version identification on xml namespaceseditorialchange agreed
Issue 98MIME-Version should not be HTTP headereditorialchange agreed
Issue 99PREPARE_INFERIORS and FAULT(InvalidInferior)minor technicalchange agreed
Issue 100Separation of delivery information from payload minor technicalchange agreed
Issue 101Identifiers and addresses in received messagesminor technicaldeferred
Issue 102Is entity identity modification to be allowed within BTP.minor technicaldeferred
Issue 103CONTEXT used only with application msgs, not with BEGIN, BEGUNminor technicaldeferred
Issue 104RESIGN, disruption and CONFIRM_ONE_PHASEminor technicalchange agreed
Issue 105Qualifier to allow automatic completion of all-cancelled cohesionsminor technicaldeferred
Issue 106Free text for all FAULTsminor technicalchange agreed
Issue 107Reply to CONFIRM_TRANSACTION if all is okeditorialchange agreed
Issue 108Participant and service identificationminor technicalchange agreed
Issue 109SOAPAction HTTP header must be presentminor technicalchange agreed
Issue 110SOAP/HTTP binding should include HTTP/SSLminor technicaldeferred

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

Status: change agreed (13 Dec 2001)
Date added: 5 Nov 2001
Submitter: Peter Furniss, Choreology
Category: minor technical
Reference: Draft 0.9, line 3460 approx
Description:
Bindings need to state explicitly the format of the "binding address" component of their addresses - this should be a requirement in the binding proforma. For the SOAP/HTTP bindings, the format is a URL
Discussion threads in email archive:    
Announcement, 5 Nov 2001    Peter Furniss, 22 Oct 2001 (bt-main)
Agreed solution:
in Carrier Protocol Binding proforma, add paragraph
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

Status: change agreed (changed 28 Feb 2002)
Date added: 5 Nov 2001
Submitter: Peter Furniss, Choreology
Category: editorial
Reference: Draft 0.9, line 1318
Description:
In the abstract message definition for BEGUN, the paragraph on address-as-inferior text ends half-way through a sentence
Discussion threads in email archive:    
Announcement, 5 Nov 2001    Peter Furniss, 15 Feb 2002
Agreed solution:
In the abstract message for 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"

Status: change agreed (changed 28 Feb 2002)
Date added: 5 Nov 2001
Submitter: Alastair Green, Choreology
Category: minor editorial
Reference: Draft 0.9, after line 4389 - Cohesive
Description: reference to "Full Superior" should be "Cohesive Superior".
Discussion threads in email archive:    
Announcement, 5 Nov 2001    Peter Furniss, 3 Jan 2002
Agreed solution:
Make the change as suggested. (if the text gets changed completed, this won't matter)
Vote result: None opposed
Vote ended: 27 Feb 2002

Issue 4: Glossary is out-of-date

Status: change agreed (changed 10 Apr 2002)
Date added: 5 Nov 2001
Submitter: Peter Furniss, Choreology
Category: editorial
Reference: Draft 0.9, line 4403ff
Description: The Glossary requires review to ensure alignment with the rest of the text
Discussion threads in email archive:    
Announcement, 5 Nov 2001
Agreed solution:
Revised glossary, aligned with model is included in draft 0.9.2.4 and review text 0.9.5
Vote details: 3 Apr 2002
Vote result: 13 for, 0 against, 0 abstentions

Issue 5: Reference to SOAP should be SOAP/HTTP

Status: change agreed (13 Dec 2001)
Date added: 5 Nov 2001
Submitter: Alastair Green, Choreology
Category: minor technical
Reference: Draft 0.9, line 965
Description:
The properties of SOAP as a carrier depend on what SOAP in turn is carried by. The sentence "Note that these assumptions would be met by a mapping to SMTP and more than met by mappings to SOAP." should refer to SOAP/HTTP.
Discussion threads in email archive:    
Announcement, 5 Nov 2001
Agreed solution: change "SOAP" to "SOAP/HTTP" as suggested
Vote ended: 10 Dec 2001
Vote result: 18 yes, 0 no, 1 abstain

Issue 6: Informative appendices - spec or primer

Status: resolved (changed 30 Jan 2002)
Date added: 5 Nov 2001
Submitter: Peter Furniss, Choreology / Mark Little, HP
Category: editorial
Reference: Appendices
Description:
Should the informative appendices be re-instated in the spec, or left for incorporation in the intended primer. (They were dropped between 0.6 to 0.9 as part of the removal of explanatory and tutorial material - in consequence, the list of authors was modified, dropping the appendix authors).
Discussion threads in email archive:    
Announcement, 5 Nov 2001    Tony Fletcher, 24 Jan 2002
Agreed solution:
The Glossary Appendix remains part of the specification (to be updated as called for in issue 4 : Glossary is out-of-date ). The appendices on 'Examples and Use cases', BTP and Business Process Management' and 'BTP and Security' are omitted from the BTP specification.
Vote result: unanimous consent
Voted: Conference call, 30 January

Issue 7: SOAP RPC

Status: change agreed (changed 16 Jan 2002)
Date added: 7 Nov 2001
Submitter: Alastair Green, Choreology
Category: technical
Description:
Existing SOAP binding does not allow for use of SOAP RPC model, which is inefficient, and makes it hard to construct thin clients without listening capacity, using standard SOAP programming toolkits.
Suggested solution:
in summary from informal messaging meeting in London, 1 November; more detail to follow.

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

Status: change agreed (changed 30 Jan 2002)
Date added: 7 Nov 2001
Submitter: Alastair Green, Choreology
Category: technical
Description:
Desire for clients which can initiate transaction, and invoke application service(s) in transactional context and terminate transaction, but cannot listen independently because of firewall or other restrictions or policies.
Suggested solution:
Given the ability to do RPC over request/response carriers (see previous issue on SOAP RPC), this is possible using the 0.9 specification facilities, by making the Factory/Decider a remote, within-the-firewall service. (Server-side transactions). No need to modify specification.
Discussion threads in email archive:    
Announcement, 7 Nov 2001    Peter Furniss, 25 Jan 2002
Agreed solution:
No change is needed.
Vote result: unanimous consent
Voted: Conference call, 30 January

Issue 9: Better explanation of Atom/Cohesion

Status: resolved (changed 15 Apr 2002)
Date added: 7 Nov 2001
Submitter: Alastair Green, Choreology
Category: editorial
Description:
We should expand the Overview of BTP section to add text similar to message to Arkin (
http://lists.oasis-open.org/archives/business-transaction/200110/msg00126.html) to give clearer and more precise definition of difference between Atom and Cohesion.
Discussion threads in email archive:    Announcement, 7 Nov 2001
Vote result: Resolved by conceptual model text; No comment on default vote ended 11 April

Issue 10: Reflect message compounding in the XML Schema

Status: change agreed (changed 13 Feb 2002)
Date added: 8 Nov 2001
Category: minor technical
Submitter: Alex Ceponkus
Description:
The current XML Schema does not contain the compounding relationships between BTP messages, nor does it contain the wrapper elements (naming still being considered, but at this time btp:transmission and btp:messages are being proposed.)
Note: This mis-alignment between text and schema emerged in the informal messaging meeting, 7 Nov.
Discussion threads in email archive:    
Announcement, 8 Nov 2001
Proposed solution:
As in the XML in draft 0.9.1.2

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

Status: change agreed (changed 13 Feb 2002)
Date added: 8 Nov 2001
Category: minor technical
Submitter: Alex Ceponkus
Description:
The schema currently represents qualifiers to have the name 'qualifier', rather then the name of the actual qualifier. Just need to define a qualifier type rather than a 'qualifier' element. Also, the predefined qualifiers (like btpq:transaction-timelimit, btpq:inferior-timeout and btpq:minimum-timeout) need to be added.
Discussion threads in email archive:    
Announcement, 8 Nov 2001    Peter Furniss, 26 Jan 2002
Proposed solution:
As in the XML in draft 0.9.1.2

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

Status: change agreed (13 Dec 2001)
Date added: 8 Nov 2001
Category: minor editorial
Submitter: Alex Ceponkus
Description:
line: 580 "confirm some Inferiors" -> "confirm to some Inferiors"

line: 785 "An Decider also REQUEST_STATUS" -> "A Decider receives also REQUEST_STATUS"

line: 880 "Decider, which may either" -> "Decider, which is either"

line: 942 "even if it also a Superior." -> "even if it is also a Superior."

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

Status: resolved (changed 15 Apr 2002)
Date added: 8 Nov 2001
Category: editorial
Submitter: Gordon Hamilton, AppliedTheory
Pages: 15,20, 21
Description:
Other than the "A Terminator is usually an application element", there does not seem to be a clear delineation of what a Terminator is. I understand that it is outside of the scope of this spec to some extent but it certainly has a linchpin role. I believe, from reading between the lines, that the Terminator is the instigator of the original Context being sent out, and a description or example might give folks a "handle" or context of their own. For example it would explain why an Inferior has decided to ENROL in a BT.
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 14: Minor editorials

Status: change agreed (13 Dec 2001)
Date added: 8 Nov 2001
Category: minor editorial
Submitter: Gordon Hamilton, AppliedTheory
Description:
Insertions shown with italics where no other changes to text
Page 12 2nd para:
"A Inferior:Superior relationship…" -> "An Inferior:Superior relationship…"
Page 12, Para 3, Sentence 3:
"The particular mechanisms by which a CONTEXT is "related" to application…" -> "The particular mechanisms by which a CONTEXT is related to an application…"
Page 16, Para 4, Sentence 1:
"A Superior may be Atomic or Cohesive. An Atomic Superior will apply the same decision to all of its Inferiors; a Cohesive Superior can apply confirm to some Inferiors and cancel to others, …"
Page 19 Para 4 Sentence 4:
"As the previous, but other access to the affected data if forbidden until the decision is known" -> "As the previous, but other access to the affected data is forbidden until the decision is known"
Page 20 Para 4 Sentence 2:
"How the confirm-set is controlled, and when is not defined in this specification." -> "How the confirm-set is controlled, and when, is not defined in this specification."
Page 20 Para 6 Sentence 3:
"If the Terminator asks the Decider to confirm the business transaction, it is the responsibility of the Decider…"
Page 20 Para last Sentence 1:
"An Decider also REQUEST_STATUS and …" -> "A Decider also receives a REQUEST_STATUS and …"
Page 27 Para 2 Sentence 2nd last:
"… otherwise the Service cannot determine that is should bundle the messages together." -> "… otherwise the Service cannot determine that it should bundle the messages together."
Page 27 Para 2 Sentence last:
"One-shot is thus a specialisation of one-wire." -> "One-shot is thus a specialization of one-wire."
Page 29 Para 5 Sentence last:
"The "superior type" parameter identifies whether the Superior will apply the same decision to all Inferiors enrolled with using the same superior identifier ("superior type" is "atom") or may apply different decisions ("superior type" is "cohesion")." ->
"The "superior type" parameter identifies whether the Superior will apply the same decision to all Inferiors enrolled by using the same superior identifier ("superior type" is "atom") or it may apply different decisions ("superior type" is "cohesion")."
Page 38 Para last Sentence 2:
"The level of isolation is a local matter (i.e. is the Inferiors choice, as constrained by the shared understanding of the application exchanges)..."
-> "The level of isolation is a local matter (i.e. it is the Inferiors choice, as constrained by the shared understanding of the application exchanges)…"
Page 50 :
"targtted." -> "targeted"
Page 64 :
"An implementation receiving a *_STATE message with "reply_requested" as "true" is not required to reply immediately - it may choose to delay any reply until a decision event occurs…"
Page 66:
"The term "remaining Inferiors" are any actors to which this endpoint …"

-> "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

Status: change agreed (changed 28 Feb 2002)
Date added: 8 Nov 2001
Category: minor technical
Submitter: Gordon Hamilton, AppliedTheory
Page: 22
Question: Is there a negative reply to the BEGIN?
Discussion threads in email archive:    
Announcement, 8 Nov 2001    Tony Fletcher, 24 Jan 2002    Peter Furniss, 15 Feb 2002
Agreed solution:
In the abstract message definition of FAULT:

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.
change the explanation of the meaning of WrongState to:
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

Vote result: None opposed
Vote ended: 27 Feb 2002

Issue 16: Negative reply to REDIRECT

Status: change agreed (changed 28 Feb 2002)
Date added: 8 Nov 2001
Category: minor technical
Submitter: Gordon Hamilton, AppliedTheory
Page: 23
Question: Is there a negative reply to the REDIRECT?
Discussion threads in email archive:    
Announcement, 8 Nov 2001    Tony Fletcher, 24 Jan 2002
Agreed solution:
No change.

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"

Status: change agreed (changed 30 Jan 2002)
Date added: 8 Nov 2001
Category: editorial
Submitter: Gordon Hamilton, AppliedTheory
Reference: Page 25 Para last Sentence 1
Description: Does the word "peer" need a definition? The first reference is :
BTP recovery requires that the state information for a Superior or Inferior is accessible after failure and that the peer can distinguish between temporary inaccessibility and the permanent non-existence of the state information.
Discussion threads in email archive:    
Announcement, 8 Nov 2001    Tony Fletcher, 24 Jan 2002
Agreed solution:
Add to the glossary
Peer : The other party in a two-party relationship, as in Superior to Inferior, or Sender to Receiver

Vote result: unanimous consent
Voted: Conference call, 30 January

Issue 18: Response to CONTRADICTION ?

Status: resolved (changed 30 Jan 2002)
Date added: 8 Nov 2001
Category: minor technical
Submitter: Gordon Hamilton, AppliedTheory
Reference: Page 47 Para mid
Current text: CONTRADICTION Sent by the Superior to an Inferior that has taken an autonomous decision contrary to the decision for the atom. This is detected by the Superior when the 'wrong' one of CONFIRMED or CANCELLED is received. CONTRADICTION is also sent in response to a HAZARD message.
Question: What is the response to a CONTRADICTION supposed to be? Especially a CONTRADICTION to a hazard.
Discussion threads in email archive:    
Announcement, 8 Nov 2001    Tony Fletcher, 24 Jan 2002
Agreed solution:
No change. CONTRADICTION is always the last message.
Vote result: unanimous consent
Voted: Conference call, 30 January

Issue 19: FAULTs from RESIGNED ?

Status: change agreed (changed 28 Feb 2002)
Date added: 8 Nov 2001
Category: minor technical
Submitter: Gordon Hamilton, AppliedTheory
Reference: Page 36 Para last Sentence 1
Current text: No FAULT messages are issued on receiving RESIGNED.????
Question: Even if you did not ask to RESIGN?
Discussion threads in email archive:    
Announcement, 8 Nov 2001    Tony Fletcher, 25 Jan 2002    Peter Furniss, 15 Feb 2002
Agreed solution:
Allow FAULT (wrongstate) and FAULT(general) as possible from RESIGNED, to be sent to the Superior address

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

No FAULT messages are issued on receiving RESIGNED
by
Types of FAULT possible (sent to Superior address)

Vote result: None opposed
Vote ended: 27 Feb 2002

Issue 20: Resending PREPARE

Status: change agreed (13 Dec 2001)
Date added: 8 Nov 2001
Category: minor technical
Submitter: Gordon Hamilton, AppliedTheory
Reference: Page 52
Current text: If PREPARED has not been received from any Inferiors in the confirm-set, PREPARE shall be issued to them. ????
Question: Even if PREPARE has been sent already?
Discussion threads in email archive:    
Announcement, 8 Nov 2001
Agreed solution:

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.


Vote ended: 10 Dec 2001
Vote result: 18 yes, 0 no, 1 abstain

Issue 21: Multiple Superior:Inferior relationships within a Cohesion

Status: resolved (changed 15 Apr 2002)
Date added: 8 Nov 2001
Category: minor technical
Submitter: Gordon Hamilton, AppliedTheory
Description:
Is it an issue that an inferior may be in multiple S:I relationships within a BT Cohesion and cancel or hazard one of them while confirming another? Or is this just an implementation detail for the Terminator functionality, where they can choose to monitor at that granular a level?

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 22: Lack of accountability reflected from D0.6 to D0.9

Status: withdrawn (changed 9 Mar 2002)
Date added: 8 Nov 2001
Category: editorial
Submitter: Bill Cox, (for all BEA members)
Submitter's identification: issue A. This issue was marked as
"procedural and editorial" by the submitter
Problem:
The transitions from D0.6 to D0.9 (including the "not distributed" drafts 0.7, 0.72, and 0.8) were not clearly based in decisions of the working group. Instead, to all appearances, the document changed rapidly and without consultation. If we take the time series from Draft 0.6 to date, it looks like we should be at draft 1.5 in a few more weeks.
Suggested remedy:
Enumerate the changes (Alistair and
Peter's email is a start), then discuss and vote on each in turn. Include rationale, or contemporaneous minutes, supporting the decisions made.
Discussion threads in email archive:    Announcement, 8 Nov 2001    William Cox, 9 Jan 2002
Note: Closed at submitter's request

Issue 23: Lack of minutes to support decisions

Status: withdrawn (10 Jan 2002)
Date added: 8 Nov 2001
Category: editorial
Submitter: Bill Cox, (for all BEA members)
Submitter's identification: issue B. This issue was marked as
"procedural and editorial" by the submitter
Problem:
On studying the email logs and web site, few meetings appear to have anything resembling contemporaneous minutes, showing decisions made and discussion justifying those changes. The document might be attacked as being less legitimate with this lack of history.
Suggested remedy:
As suggested elsewhere, ensure that minutes for meetings and specific minuted (is that a word?) discussions on the topics support the editor's current draft. Taking inventory of contemporaneously-written minutes and filing them on the web site in addition to the several already there would add to the apparent well-foundedness of the Draft and the group effort.
Discussion threads in email archive:    
Announcement, 8 Nov 2001    William Cox, 9 Jan 2002

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

Status: resolved (changed 1 May 2002)
Date added: 8 Nov 2001
Category: technical
Submitter: Bill Cox, (for all BEA members)
Submitter's identification: issue C
Detail:
The model as described loses much from the complexity of overloading terms and messages. The model might indeed NOT be too complex, but that conclusion cannot be drawn from the draft as written. The specification is less attractive due to the apparent complexity. Simplification in exposition and possible simplification of the model after clarification is important to make BTP well accepted and understood.
Suggested remedy:
After editorial changes to clarify the model, a review cycle is needed to understand whether the revised document's model as presented is "as simple as possible but no simpler."
Discussion threads in email archive:    
Announcement, 8 Nov 2001
Vote result: Comment on default vote ended 11 April, see message from Bill Cox.
Agreed solution: Resolved by conceptual model, including resolution to issue 66 : Event diagram for termination protocol

Issue 25: Clarity needed between atomic and cohesion

Status: resolved (changed 1 May 2002)
Date added: 8 Nov 2001
Category: technical
Submitter: Bill Cox, (for all BEA members)
Submitter's identification: issue D
Summary:
Greater clarity needed between atomic and cohesion--the terminology for cohesion makes the terminology for atomic less clear
Detail:
The draft attempts to reconcile two different levels and kinds of protocols: one where the action fails or succeeds (Atomic), and another where a higher level protocol (Cohesion) deals with the recovery from failures while working toward a more complex goal. Abstract terms (e.g. superior/inferior) require confusing "mental casting," especially since an actor can be either of those roles in a binary interaction.
Suggested remedy:
Define conformance so that "core conformance" is all and only what is needed for atomic. Creating separate sections for Atomic BTP and Cohesion BTP would clarify. Ensure that Atom can stand alone.
Discussion threads in email archive:    
Announcement, 8 Nov 2001
Vote result: Comment on default vote ended 11 April, see message from Bill Cox
Agreed solution: Resolved by conceptual model and conformance text, including resolution to issue 87 : Conformance Level

Issue 26: Multiple conformance points should be defined.

Status: resolved (changed 1 May 2002)
Date added: 8 Nov 2001
Category: technical
Submitter: Bill Cox, (for all BEA members)
Submitter's identification: issue E
Detail:
Alistair Green's and
Mark Potts' separate suggestions on conformance partially addresss the problems caused by combining cohesion and atomic. Some restructuring of the Draft will be necessary, probably into separate sections for atomic and cohesion.

(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.

Status: resolved (changed 15 Apr 2002)
Date added: 8 Nov 2001
Category: editorial
Submitter: Bill Cox, (for all BEA members)
Submitter's identification: issue F
Detail:
The exposition makes this document very difficult to understand. It is not adequate to say that talking someone through it helps them understand -- the document should be accessible from the written form, which is what will be standardized. It is NOT enough that the editor and a few others can understand the Draft if the goal is a broadly adopted public specification. The previous elimination of what was called "Primer" material damaged the accessibility of BTP.
Suggested remedy:
Restore material with the goal of accessibility, and do a careful review including non-initiates to ensure that the revised draft is clear and understandable, and that presumably non-normative material is consistent with the normative.
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 28: Need for state diagrams and explanatory text

Status: resolved (changed 15 Apr 2002)
Date added: 8 Nov 2001
Category: editorial
Submitter: Bill Cox, (for all BEA members)
Submitter's identification: issue G
Summary:
State tables should be augmented by state diagrams and more explanatory text.
Detail:
The state tables are particularly opaque, requiring much work to understand them (and, coincidentally, much more work to meaningfully comment).
Suggested remedy:
Include state diagrams in the Draft in addition to the state tables. Review to ensure that the normative state diagrams are consistent with the normative state tables, and that the protocol machine is clearly presented.
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 29: Redirection

Status: change agreed (changed 28 Mar 2002)
Date added: 8 Nov 2001
Submitter: Bill Cox, (for all BEA members)
Submitter's identification: issue H
Submitter's title: Participant timeout impact needs further discussion.
Note: The original title doesn't seem to correspond to the substance
Category: technical
Detail:
(Submitter documents are email from
Alistair Green 20011023, BEA 20011018 - hyperlinks added PRF) Alistair Green's rebuttal, supporting including transport functionality into BTP, has a sound motivation, but complicates BTP while violating generally accepted layering approaches. At the least, this belongs in a separate specification (SOAP with redirection? Generic redirection protocol?). His argument that it is necessary doesn't mean it should be standardized via a back door such as BTP. There are many other things about which one could make the same argument. (e.g., reliable messaging, dealing with failed message routers)
Suggested remedy:
Eliminate the redirector and related message from the specification. Submit this functionality to an appropriate standards group, e.g. W3C XML Protocols. In the alternative, break it out clearly as an enhancement to messaging services, and giving it a separate section to make separate use easier.
Discussion threads in email archive:    Announcement, 8 Nov 2001    Peter Furniss, 25 Jan 2002    Peter Furniss, 1 Mar 2002
Proposed solution:
Rationale

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-typemeaningfault-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.

Status: change agreed (changed 13 Feb 2002)
Date added: 8 Nov 2001
Category: technical
Submitter: Bill Cox, (for all BEA members)
Submitter's identification: issue I
Detail:
Per Alistair Green's "wrinkle" in
email on 20011023. We agree with him that all coordinators should be assumed to be potential sub-coordinators. This avoids a legacy integration problem that he points out, as well as simplifying the coordinator definition.
Suggested remedy:
Add text to the Draft so stating.
Dependent issue: Issue 2
Discussion threads in email archive:    Announcement, 8 Nov 2001    Peter Furniss, 6 Feb 2002
Proposed solution:
In abstract message for BEGUN

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 inferior-handle desription

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.

Status: withdrawn (changed 9 Mar 2002)
Date added: 8 Nov 2001
Submitter: Bill Cox, (for all BEA members)
Submitter's identification: issue J
Category: editorial
Detail:
The Draft attempts to describe BTP (as of 0.9) without explanation and without explicit rationale in many places. This is one of a number of factors that makes the Draft and BTP difficult to understand. Most other specifications make a distinction between rationale, examples, and normative text.
Suggested remedy:
Include rationale in a typographically distinct manner throughout the Draft. This should be grounded in minutes of meetings.
Discussion threads in email archive:    
Announcement, 8 Nov 2001
Note: Closed at submitter's request

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

Status: resolved (changed 15 Apr 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: minor editorial
Submitter's identification: #1
Description:
First use of "Business Transaction" should be italicised, IMO. Page 11.
Line: 362
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 33: Rewording

Status: change agreed (13 Dec 2001)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: editorial
Submitter's identification: #2
Description:
Page 11, change 'has to' at end of paragraph 3 to ‘should have’, since we all know that heuristics happen that can’t be resolved, and catastrophic failures also occur.
Line: 374
Discussion threads in email archive:    
Announcement, 8 Nov 2001
Agreed solution:
Text to read
Those parties which are confirmed create an atomic unit, within which the business transaction should have a consistent final effect.

Vote ended: 10 Dec 2001
Vote result: 19 yes

Issue 34: Superior and Inferior

Status: resolved (changed 15 Apr 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: editorial
Submitter's identification: #3
Description:
Last paragraph of page 11, here we dive off into Superior and Inferior. It would be better if we had some preliminary definition of these terms (possibly based on the previous paragraphs) that we could then relate to. Obviously this definition could then be enhanced as the document progresses.
Line: 403-408
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 35: Superior and Inferior (2)

Status: resolved (changed 15 Apr 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: editorial
Submitter's identification: #4
Description:
Second paragraph page 12: This is part of the definition I’m after for previous issue, but comes too late.
Line: 410-413
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 36: Two-phase cancel - NOT

Status: resolved (changed 15 Apr 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: editorial
Submitter's identification: #5
Description:
Page 12, second paragraph: "Inferior which cannot prepare to cancel/confirm". This implies that we have a two-phase cancel stage, i.e., that in order to cancel I still need to issue prepare.
Line: 415/416
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 37: Acceptable to application or participant

Status: resolved (changed 15 Apr 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: editorial
Submitter's identification: #6
Description:
Page 13, last paragraph: "In addition, a cancellation may not return data to their original state, but only to a state accepted by the application as appropriate to a cancelled operation." It would be more correct to say “acceptable to the participant”, because there is no negotiation inherent in BTP to do what is implied currently.
Line: 459/460
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 38: First use of "cohesion"

Status: resolved (changed 15 Apr 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: editorial
Submitter's identification: #7
Description:
First point 1, page 15: Cohesion - First use, and why is this here in any case? This may be confusing to first-time readers.
Line: 518
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 39: Resigning Inferior

Status: resolved (changed 28 Feb 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: minor technical
Submitter's identification: #8
Description:
Page 16, change text to read: "An inferior can remove itself from a given Superior:Inferior relationship by resigning (sending a RESIGN message). If RESIGN is received from an Inferior, and the Inferior is allowed to leave the protocol, then the Superior:Inferior relationship is ended; the Inferior has no further effect on the behaviour of the Superior as a whole."
Line: 584,585 (replacing paragraph)
Discussion threads in email archive:    
Announcement, 8 Nov 2001    Peter Furniss, 27 Nov 2001    Peter Furniss, 15 Feb 2002
Original category: editorial
Agreed solution:
No change

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

Status: resolved (changed 10 Apr 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: editorial
Submitter's identification: #9
Description:
Page 16, change last bit of text to read: "A Superior need not acknowledge that the Inferior has been enlisted in the relationship. However, if requested to by the sender of ENROL (if the appropriate parameter on the ENROL is set) then the Superior sends" and remove "if the appropriate parameter on the ENROL asked for the reply" after the "in reply to ENROL."

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

Status: change agreed (changed 20 Mar 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: editorial
Submitter's identification: #10
Description:
Page 19, first paragraph: "ENROL/no-rsp-req" - First time this short-hand has been used. It should be described before this point.
Line: 694
Discussion threads in email archive:    
Announcement, 8 Nov 2001    Tony Fletcher, 28 Jan 2002
Proposed solution:
No change

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

Status: resolved (changed 15 Apr 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: editorial
Submitter's identification: #11
Description:
Page 20, "An Inferior which is also a Cohesive Superior" - I think we are missing some of the useful introduction text/diagrams that existed in earlier drafts. These gave an overview of the atom/cohesion/participant relationships, and some of the text in this draft only really works if that introduction exists.
Line: 745
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 43: REQUEST_STATUS and STATUS coupling

Status: resolved (changed 15 Apr 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: editorial
Submitter's identification: #12
Description:
Page 21, talks about the REQUEST_STATUS and STATUS replies. Why is this message coupling not in the above list?
Line: 785,786
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 44: Decider and other terms

Status: resolved (changed 15 Apr 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: editorial
Submitter's identification: #13
Description:
Page 22 keeps switching between Decider, (Cohesion) Composer, and Coordinator. This gets confusing.
Line: 825-859 (description of Terminator)
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 45: Compound addresses

Status: resolved (changed 15 Apr 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: editorial
Submitter's identification: #14
Description:
The issue about being able to have compound addresses is not clearly laid out. Can we move some of the paragraphs about this to much earlier in the document, perhaps at some model/architecture section?

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

Status: change agreed (13 Dec 2001)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: minor technical
Submitter's identification: #15
Description:
Page 26, when describing "A+B": I believe at the last London face-to-face we also discussed that the order would be important.
Line: 1053
Discussion threads in email archive:    
Announcement, 8 Nov 2001
Agreed solution:
Add to the sentence, making the paragraph (0.9, lines 1052, 1053):
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.

Vote ended: 10 Dec 2001
Vote result: 17 yes, 1 no, 1 abstain

Issue 47: Handle and Identifier

Status: resolved (changed 30 Jan 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: technical
Submitter's identification: #16
Description:
Is there anything preventing a Handle being the same as an Identifier? I know that the inverse doesn't make sense, but Handle-to-Identifier would appear to.
Line: 1133-1138
Discussion threads in email archive:    
Announcement, 8 Nov 2001    Peter Furniss, 25 Jan 2002
Agreed solution:
The proposed solution to issue 77 : Inferior identification , which in turn depends on the resolution of issue 78 : Addresses used for identification , removes the handles completely and just uses identifiers.
Vote result: unanimous consent
Voted: Conference call, 30 January

Issue 48: completion of enrollment

Status: resolved (changed 15 Apr 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: minor technical
Submitter's identification: #17
Description:
What does "or will be completed by ENROL messages sent in relation to the CONTEXT_REPLY" on page 30, first paragraph refer to?
Line: 1215/1216
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 49: type of Handle

Status: resolved (changed 30 Jan 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: technical
Submitter's identification: #17 (again)
Description:
There is no definition of what a Handle is, e.g., a hex string, a free form string, ...
Line: 1142
Discussion threads in email archive:    
Announcement, 8 Nov 2001    Mark Little, 24 Jan 2002 (bt-main)    Peter Furniss, 25 Jan 2002
Dependent issue: Issue 47
Note: Recategorised because 47 was "technical", but depends on resolution of this one.
Agreed solution:
The resolution is to remove the use of handle and replace it with identifer. Depends on issue 47 : Handle and Identifier , which depends on issue 77 : Inferior identification , which depends on issue 78 : Addresses used for identification .
Vote result: unanimous consent
Voted: Conference call, 30 January

Issue 50: Default parameter values

Status: change agreed (changed 28 Feb 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: technical
Submitter's identification: #18
Description:
Did we ever discuss default values for:

(i) reply requested [false]

(ii) response-requested [no default as far as I can tell, but I'd suggest true if sent before a PREPARE, and false otherwise.]

(iii) report hazard [false]

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

Status: change agreed (13 Dec 2001)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: editorial
Submitter's identification: #19
Description:
Add ", and is only accepted by the Superior if the Inferior has not sent a PREPARED message" to the end of the first paragraph under RESIGN on page 35.
Line: 1403
Discussion threads in email archive:    
Announcement, 8 Nov 2001
Agreed solution:
leave the first paragraph (0.9 1401, 1403) as it is, and change the second paragraph (1405, 1406) to:
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.

Vote ended: 10 Dec 2001
Vote result: 19 yes

Issue 52: Forms of PREPARE

Status: resolved (changed 30 Jan 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: minor technical
Submitter's identification: #20
Description:
Page 38, last paragraph before PREPARED, talks about different forms of PREPARE. So what form is used for preparing a (sub-)coordinator?
Line: 1519-1522
Discussion threads in email archive:    
Announcement, 8 Nov 2001    Peter Furniss, 17 Jan 2002
Agreed solution:
Resolved by agreed solution to issue 79 : Normalising the message set
Note:
PREPARE is sent by Superiors to Inferiors - since Sub-coordinators and Sub-composers are Inferiors, they receive PREPARE from their Superior

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 ?

Status: resolved (changed 15 Apr 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: minor technical
Submitter's identification: #21
Description:
Page 45, Note on CANCELLED says that the "latter will cause a CONTRADICTION". Surely it’s “may”, since if this is the first participant to be sent CONFIRM, and I get back CANCEL, I may well be able to reverse my decision and send CANCEL to all other participants. Although the outcome is then contrary to what I may have originally wanted, all participants are consistent on the decision.
Line: 1796
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 54: hazard forms

Status: change agreed (13 Dec 2001)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: minor technical
Submitter's identification: #22
Description:
Page 48 talks about "hazard forms": Where do these “forms” come in? Are they only for discussing aspects of the protocol, or do they occur in the message set? It would be useful if this form of HAZARD information (mixes/possible) was in the message set.
Line: 1864-1865
Discussion threads in email archive:    
Announcement, 8 Nov 2001
Agreed solution:

In abstract message section on HAZARD
Add row to HAZARD parameter list
levelmixed/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"

Vote ended: 10 Dec 2001
Vote result: 18 yes, 1 no

Issue 55: CONFIRM_ONE_PHASE and PREPARE

Status: change agreed (13 Dec 2001)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: minor technical
Submitter's identification: #23
Description:
Page 53: "If there is only one remaining Inferior in the “confirm set”, CONFIRM_ONE_PHASE may be sent to it." Only if it has not already had a PREPARE sent to it?
Line: 2043,2044
Discussion threads in email archive:    
Announcement, 8 Nov 2001
Agreed solution:
Add before the comma in line 2043 (drft 0.9),
and PREPARE has not been sent to it

Vote ended: 10 Dec 2001
Vote result: 19 yes

Issue 56: State table text

Status: resolved (changed 15 Apr 2002)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: editorial
Submitter's identification: #24
Description:
The text that is supposed to cover the State Table seems more appropriate to a general implementation view of BTP, and not just the interpretation of the state table.
Line: 2501ff
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 57: XML Schema applicable to more than SOAP

Status: change agreed (changed 16 Jan 2002)
Date added: 8 Nov 2001
Category: editorial
Submitter: Tony Fletcher, Choreology
Description:
The XML schema for the messages is given under the heading 'XML Schema for SOAP Bindings'. This would seem to suggest that this XML schema is tied to this particular binding and there could be other XML schema for other bindings. I do no think that is what is intended. I therefore propose that an 'XML Schema' section is added following the specification of the message in abstract form and that this sections (and any other bindings that use the XML schema) reference the one XML schema specification.
Discussion threads in email archive:    
Announcement, 8 Nov 2001    Peter Furniss, 3 Jan 2002
Agreed solution:
This is included in draft 0.9.0.4.

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

Status: change agreed (13 Dec 2001)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: minor editorial
Submitter's identification: #25
Description:
Word document (1.5Mb) is a marked up version of the spec. with several spelling mistakes and missing words. It also has many of the issues I've just sent you as comments, just in case. (issues now numbered 32 - 56, prf))
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, 0 no, 1 abstain

Issue 59: Interposition description needed

Status: resolved (changed 15 Apr 2002)
Date added: 12 Nov 2001
Submitter: Mark Little, HP
Category: editorial
Description:
(extracted from Mark <-> Peter email exchange)

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

Status: change agreed (changed 20 Mar 2002)
Date added: 19 Nov 2001
Category: minor technical
Submitter: Peter Furniss, Choreology
Description:
The abstract message descriptions call the address parameters "address-as-superior", "address-as-inferior", "address-as-decider", intending to be clear that these are addresses the actor in question offers for that role (i.e. as the target of particular future messages), given that the actor may also offer other addresses for that role (or indeed the same address, but for a different role)

The xml constructs call these "superior address" etc., which is shorter, and perhaps more message-oriented. (a PREPARE for example travels from the Superior (for this relationship) to the address-as-inferior of the Inferior of the relationship.

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

Status: change agreed (changed 10 Apr 2002)
Date added: 19 Nov 2001
Category: editorial
Submitter: Alastair Green, Choreology
Note: This concept was originally proposed by Sanjay and it was meant to be included in the document, but never has been.
Description:
For each role, there should be table stating which messages are sent and which received for that role. This will be clearer than the list presentation used in 0.9.
Dependent issue:
Issue 40
Discussion threads in email archive:    Announcement, 19 Nov 2001    Sazi Temel, 3 Feb 2002
Agreed solution:
Tables of sent and received messages have been added in draft 0.9.2.4 and review text 0.9.5
Vote details: 3 Apr 2002
Vote result: 13 for, 0 against, 0 abstentions

Issue 62: Names of the relationships

Status: change agreed (changed 16 Jan 2002)
Date added: 19 Nov 2001
Category: minor technical
Submitter: Alastair Green, Choreology
Description:
The two distinct relationships in BTP are called "Superior:Inferior" and "Terminator:Decider" in 0.9. These names are cumbersome, and in the latter case, not very accurate - the client-end application to coordination-facility relationship includes Initiator:Factory. Simple names would clarify.

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

Status: resolved (changed 15 Apr 2002)
Date added: 21 Nov 2001
Category: editorial
Submitter: Sazi Temel, BEA Systems
Description:
Throughout the spec, actors and roles are many times used interchangeably, and even sometimes the relationship is used instead of name of a role. Is Coordinator a role or a actor? Is superior-inferior an actor or a relationship? These all depends on what the definition of these terms are and we should clarify it very well.

These were source of some discussions in the past and looks like we can eliminate similar discussions in the future by clear definitions.

Here is an attempt to define actors, roles and relationships.

Actors and roles are an important part of any system modeling interacting entities in multiple contexts. An actor is an entity in a system, a doer with properties and capabilities. An actor has properties and services that are relevant across all the contexts in the system. A role is an actor within a context (relationship) An actor can 'play' multiple roles in a system, but only one in a given context. A role is played by only one actor and without the actor it is not valid.

For example while a BTP Coordinator is an actor that may play the role of Cohesion Composer, Atom Coordinator or a Sub-coordinator depending on the context in which it is referred, a superior or an inferior is not a role (but a relationship) since many actors in the system takes these roles, in fact all the actors in BTP are either superior or inferior.


Discussion threads in email archive:    
Announcement, 21 Nov 2001

Vote result: Resolved by conceptual model text; No comment on default vote ended 11 April

Issue 64: can inferior know type of superior ?

Status: resolved (changed 15 Apr 2002)
Date added: 22 Nov 2001
Category: minor technical
Submitter: Pyounguk Cho(Pyounguk.Cho@iona.com)
Detail: Can an inferior tell whether its superior is
a (sub)coordinator or a (sub)composer?
Discussion threads in email archive:    
Announcement, 22 Nov 2001
Vote result: Resolved by conceptual model text; No comment on default vote ended 11 April

Issue 65: participant as immediate inferior of composer ?

Status: resolved (changed 15 Apr 2002)
Date added: 22 Nov 2001
Category: minor technical
Submitter: Pyounguk Cho(Pyounguk.Cho@iona.com)
Detail: Can a composer have a participant as its immediate inferior?

Discussion threads in email archive:    
Announcement, 22 Nov 2001    Peter Furniss, 26 Nov 2001    Peter Furniss, 17 Dec 2001    Sanjay Dalal, 15 Jan 2002
See also issue: Issue 62
Vote result: Resolved by conceptual model text; No comment on default vote ended 11 April

Issue 66: Event diagram for termination protocol

Status: change agreed (changed 1 May 2002)
Date added: 22 Nov 2001
Category: editorial
Submitter: Pyounguk Cho(Pyounguk.Cho@iona.com)
Detail: For both Atom and Cohesion case, it might be helpful to add an event diagram that shows the type of messages sent in the 1st and 2nd phase in different scenarios

Discussion threads in email archive:    
Announcement, 22 Nov 2001
Vote result (first vote): Comment on default vote ended 11 April, see message from Bill Cox
Agreed solution:
Some of the existing diagrams, figure 9 and figure 16 (as numbered in 0.9.5.1), in the model section include the termination sequence, and figure 13 shows the state sequence for a Composer or Coordinator.

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 ?

Status: change agreed (changed 28 Feb 2002)
Date added: 22 Nov 2001
Category: minor technical
Submitter: Pyounguk Cho(Pyounguk.Cho@iona.com)
Detail: Is it possible to have a "Hazard" as a result of autonomous decision"

Discussion threads in email archive:    
Announcement, 22 Nov 2001    Tony Fletcher, 15 Feb 2002
Agreed solution:
In the abstract message section fro HAZARD

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.

Vote result: None opposed
Vote ended: 27 Feb 2002

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

Status: resolved (changed 15 Apr 2002)
Date added: 22 Nov 2001
Category: minor technical
Submitter: Pyounguk Cho(Pyounguk.Cho@iona.com)
Detail: Is it possible to have (sub)coordinators or (sub)composers as inferiors when they have no inferiors?
Suggested remedy:
(sub)coordinators and (sub)composers should be delisted automatically when all of their inferiors have resigned.
Discussion threads in email archive:    
Announcement, 22 Nov 2001
Vote result: Resolved by conceptual model text; No comment on default vote ended 11 April

Issue 69: prepared subcomposer with unprepared inferiors ?

Status: resolved (changed 15 Apr 2002)
Date added: 22 Nov 2001
Category: minor technical
Submitter: Pyounguk Cho(Pyounguk.Cho@iona.com)
Detail: Can a subcomposer be prepared when some of its inferiors cannot be prepared?

Discussion threads in email archive:    
Announcement, 22 Nov 2001
Vote result: Resolved by conceptual model text; No comment on default vote ended 11 April

Issue 70: Confirm-set evolution

Status: resolved (changed 15 Apr 2002)
Date added: 22 Nov 2001
Category: minor technical
Submitter: Pyounguk Cho(Pyounguk.Cho@iona.com)
Detail: When and how does the confirm-set evolve?

Discussion threads in email archive:    
Announcement, 22 Nov 2001
Vote result: Resolved by conceptual model text; No comment on default vote ended 11 April

Issue 71: Messages for Terminator

Status: resolved (changed 28 Feb 2002)
Date added: 22 Nov 2001
Category: editorial
Submitter: Pyounguk Cho(Pyounguk.Cho@iona.com)
Detail: Because two different types of Terminators exist in BTP, it would be better to tell which messages are for which type of Terminator. For instance, CANCER or CANCEL/inferiors is only for composer?

Discussion threads in email archive:    
Announcement, 22 Nov 2001    Tony Fletcher, 12 Feb 2002
Agreed solution:
Normalisation of the message set issue 79 : Normalising the message set separated the names - CANCEL_TRANSACTION is sent to any kind of Decider, CANCEL_INFERIORS only to Decider-Composers, CANCEL to Inferiors.

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


Issue 72: Scope of Context

Status: resolved (changed 15 Apr 2002)
Date added: 22 Nov 2001
Category: technical
Submitter: Pyounguk Cho(Pyounguk.Cho@iona.com)
Detail: In the presence of subcoordinators or subcomposers in the transaction tree(ct_root: context for the root composer/coordinator, ct_sub1/2/..: context of the subcomposer/subcoordinator), 1) What's the relationship of ct_root with ct_sub1/2/..? 2) What's the relationship of ct_sub1 with ct_sub2? 3) Does ct_sub1 has a ref to ct_root or vice versa? 4) Does ct_root span to participarnts that are not immediate?

Discussion threads in email archive:    
Announcement, 22 Nov 2001
Vote result: Resolved by conceptual model text; No comment on default vote ended 11 April

Issue 73: ACID relaxation in overview

Status: resolved (changed 20 Apr 2002)
Date added: 22 Nov 2001
Category: editorial
Submitter: Pyounguk Cho(Pyounguk.Cho@iona.com)
Detail: BTP seems to relax atomicity as well as isolation and durability considering its capacity to allow partial outcome(it's not "all or nothing").
Discussion threads in email archive:    
Announcement, 22 Nov 2001
Vote result: Comment on default vote ended 11 April, see message from Bill Cox

Issue 74: WrongState from CONFIRM_ONE_PHASE

Status: change agreed (changed 30 Jan 2002)
Date added: 27 Nov 2001
Category: editorial
Submitter: Alex Ceponkus
Description:
On line 1828 of the word copy of spec version 0.9.0.1 a fault reads: "WrongState: if a PREPARE has already been received from this Inferior"

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.

Status: resolved (changed 15 Apr 2002)
Date added: 29 Nov 2001
Category: technical
Submitter: Sazi Temel, BEA Systems
Detail: (How) Does a Composer or Coordinator know that all the participants in a particular transaction enrolled? By explicit enrolling a coordinator or composer only knows those participants that are enrolled, but does not know whether all services that are in transaction enrolled their respective participants. A service may be received request from an initiator in a BT but for some reasons its participant may not be able to enroll with composer/coordinator.
Discussion threads in email archive:    
Announcement, 29 Nov 2001
Vote result: Resolved by conceptual model text; No comment on default vote ended 11 April

Issue 76: Need for explanatory material

Status: resolved (changed 15 Apr 2002)
Date added: 29 Nov 2001
Submitter: Mark Little, HP
Category: editorial
Description:
I'm not sure if this is covered by other issues, but I definitely think we should put back some (if not all) of the introductory text from 0.6. After having talked to people who aren't involved in this specification, and trying to read it from their p.o.v. it's difficult to understand now. It's OK us having a separate primer, but if there is no introductory material to put the specification into context, then we cannot release the specification without the primer. Some context is required to understand why we have atoms, cohesions, and other actors. What is the architecture we're assuming, for example?
Discussion threads in email archive:    
Announcement, 29 Nov 2001
Vote result: Resolved by conceptual model text; No comment on default vote ended 11 April

Issue 77: Inferior identification

Status: change agreed (changed 30 Jan 2002)
Date added: 30 Nov 2001
Submitter: Choreology
Category: minor technical
Description:
An inferior is identified in messages in the outcome (superior:inferior) relationship by the combination of inferior identified and inferior address, and in the control relationship (Terminator:Decider) by an inferior handle. However, in many cases, the inferior handle is also known to the inferior and it would be convenient to use when available.

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

Status: change agreed (changed 13 Feb 2002)
Date added: 30 Nov 2001
Submitter: Choreology
Category: minor technical
Description:
Many messages have the address of their sender as a parameter, only to disambiguate the identifier, because the other side already knows the sender's address.

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

REDIRECT will need changing but details can be handled under issue 29 : Redirection

BEGUN will need changing but details is can be handled under issue 30 : Assume that coordinators are potential sub-coordinators.

TRANSACTION_CONFIRMED, TRANSACTION_CANCELLED - delete address-as-decider

INFERIOR_STATUSES - delete responders-address

Change the section Identifiers in the XML section

Identifiers shall be globally unambiguous

Note - Apart from their generation, the only operation the BTP implementations have to perform on identifiers is to match them.

In the section on abstract messages, addresses (line 1051 in 0.9.1) delete the sentence "In cases b) and c), the identifier is to some extent redundant, although interoperation requires that it always be present."

Replace the text on Identifiers in the XML section and move it to the beginning of the abstract message section. New text to be:

Identifiers shall be URIs

Note – Identifiers need to be globally unambiguous. Apart from their generation, the only operation the BTP implementations are required to perform on identifiers is to match them.

In the model, state the identifier : address relation. In summary (may be modified to fit in the rest of the model, e.g. avoiding forward reference of particular terms):

An Identifier is a globally unambiguous identification of the state corresponding to one of Decider, Superior or Inferior. Where a single actor has more than one of these roles (at the same node in the same transaction), the Identifiers may be the same or different, at implementation option - they are distinguished by which messages the Identifier is used on. (A Superior has only one superior-identifier, although it may be in multiple Superior:Inferior relationships, each with a separate state in terms of the state table).

The state identified by an Identifier can be accessed by BTP messages sent to any of the addresses supplied with the Identifier in the appropriate message (CONTEXT, BEGUN, ENROL), or as updated by REDIRECT. An Identifier itself has no location implications. (Identifiers are specified, in the XML representation, as syntactically URIs - by their use as names of BTP entities, they are URNs. If an Identifier happens to specify an network location (i.e. it is a URL), it is treated as an opaque value by BTP)

Identifiers are specified as being globally unambiguous - the same Identifier only ever identifies one Decider, Superior or Inferior over all systems and all time. In practice, an Identifier could be re-used if there is no possibility of the colliding values being confused. However implementations are recommended to use truly unambiguous Identifiers (that is to use them as URNs).


Note on revision of proposal:
After 30 January conference call discussion

The proposal here has been aligned with the changes actually made in 0.9.1.1 - the definition of the Identifier as a URI is in the XML representation section. The note proposed has been shortened.

The last part of the penultimate paragraph may depend on the resolution of issue 101 : Identifiers and addresses in received messages or issue 102 : Is entity identity modification to be allowed within BTP.

The first proposed solution is included in the calling notice for the 30 January meeting.
Voted: 13 February 2002, unanimous


Issue 79: Normalising the message set

Status: change agreed (changed 16 Jan 2002)
Date added: 30 Nov 2001
Submitter: Choreology
Category: technical
Description:
The BTP abstract message set should be split into subsets, each applicable to one of the "relationships" in BTP. The division should be reflected in the XML.

BTP Draft 0.9 covers the two "relationships" (control, outcome are names for these suggested in issue 62), but has a single set of messages. Some messages are used in only one relationship (REQUEST_CONFIRM in control, ENROL, CONFIRM in outcome), but some are used in both (PREPARE, CANCEL). The ones used in both tend to have some parameters used only in one case, some only in another.

Splitting the message set will not cause any difference in functionality - the same semantics can be exchanged between the various roles. It will simplify the abstract message specification, and the xml schema, and in turn should make implementation simpler (especially for implemenations that choose to support only the Superior:Inferior relationship and use an internal API for transaction control by the application. ) It should also make the conformance discussion and specification easier.

For XML, the names can easily be qualified by namespace, and it seems it will be simplest to invent something similar for the abstract messages - thus PREPARE would become CONTROL.PREPARE and OUTCOME.PREPARE.

There should also be a separate basic group, which would include things like FAULT and CONTEXT that are used in both relationships.

Possibly the Initiator:Factory relationship (using BEGIN, BEGUN) should have its own group (Factory)
Note: The choice of a single message set was made on the principle of
conservatism - in adding the coordinator and cohesion control messages [omitted from 0.6, which had not caught up with tc decisions], we were considered making two disjoint message sets, but concluded this would appear as to great a change.
Discussion threads in email archive:    
Announcement, 30 Nov 2001    Peter Furniss, 14 Dec 2001    Peter Furniss, 12 Jan 2002
Agreed solution:
Presented here in outline, draft 0.9.0.4 includes the changes in detail.

Rename the messages used in both outcome and control, as in the table below. Use the groupings (general, outcome, control) as headings in the abstract message set, reordering the messages appropriately. Separate out the parameters and paragraphs explaining the different parts where one old message becomes a pair of new ones.

REQUEST_STATUS continues to be sent to any transaction tree node, and so can REQUEST_INFERIORS_STATUS, but they can reject the request with a FAULT(StatusRefused) (except in the case of REQUEST_INFERIORS_STATUS from Terminator to Decider).

Separate old CANCEL/whole and CANCEL/inferiors (both Terminator:Decider) into CANCEL_TRANSACTION and CANCEL_INFERIORS (original CANCEL is Superior:Inferior).
Old nameName in outcomeName in control
BEGIN BEGIN
BEGUN BEGUN
ENROLENROL 
ENROLLEDENROLLED 
RESIGNRESIGN 
RESIGNEDRESIGNED 
PREPAREPREPAREPREPARE_INFERIORS
PREPAREDPREPARED 
CONFIRMCONFIRM 
CONFIRMEDCONFIRMEDTRANSACTION_CONFIRMED
CANCELCANCELCANCEL_TRANSACTION
CANCEL_INFERIORS
CANCELLEDCANCELLEDTRANSACTION_CANCELLED
CONFIRM_ONE_PHASECONFIRM_ONE_PHASE 
HAZARDHAZARD 
CONTRADICTIONCONTRADICTION 
SUPERIOR_STATESUPERIOR_STATE 
INFERIOR_STATEINFERIOR_STATE 
REQUEST_CONFIRM CONFIRM_TRANSACTION
REQUEST_STATUSES[1]REQUEST_INFERIOR_STATUSES
INFERIOR_STATUSES[1]INFERIOR_STATUSES
REDIRECTREDIRECT 

The following do not have their names changed: REQUEST_STATUS, CONTEXT, CONTEXT_REPLY, STATUS, FAULT

[1] - REQUEST_INFERIOR_STATUSES can be sent to any transaction tree node. Whether it replies is its choice, and whether it has any inferiors can be inferred from the replying INFERIOR_STATUSES. (both this, and REQUEST_STATUS are really "management" messages, and how the Status_Requestor got hold of the address, and which one it really is, is out of our scope).

Align the xml definitions with the changes above, but keeping a single schema and namespace for the messages.
Voted: Conference call, 16 January 2002
Vote result: unanimous consent


Issue 80: CONTEXT_REPLY unnecessary for CONTEXT/cohesion

Status: change agreed (changed 16 Jan 2002)
Date added: 30 Nov 2001
Submitter: Choreology
Category: minor technical
Description:
There appears to be no requirement derived from "checking" for a CONTEXT_REPLY to be received if the CONTEXT was for a cohesion.

CONTEXT_REPLY for an Atom is to ensure that all attempted enrols for the atom worked, and avoid risk of an "orphan" inferior that the coordinator doesn't know about when it confirms. If there were such, the atom could apparently confirm when work has been done in the atom that isn't known about - the rest of the atom confirms and this orphan will (probably) eventually cancel. To prevent this, checking rules apply - until the CONTEXT_REPLY comes back, confirmation is not allowed.

But with a propagated *Cohesion* CONTEXT, there is no reason why Inferiors can't be missed out. The Terminator will determine the confirm-set on the basis of which Inferiors are enrolled - if it has an acceptable set, but there is a late-arriving ENROL, that would-be inferior just gets missed out.

There is a possibility that something that tried to ENROL in a Cohesion but failed to contact the Superior might want to send CONTEXT_REPLY/repudiated back towards the application initiator to say that there was a problem.

CONTEXT_REPLY for a cohesion may also be needed in the one-shot case (see separate issue on one-shot)
Discussion threads in email archive:    
Announcement, 30 Nov 2001    Peter Furniss, 12 Jan 2002
Agreed solution:
Accept the concept as proposed - for a CONTEXT/cohesion, there is no requirement to ensure that all the propagations of the CONTEXT are "counted back" with either CONTEXT_REPLY/completed or CONTEXT_REPLY/related and successful enrollment.

An Inferior attempting to enrol with a cohesive superior shall have the ability to ensure its enrollment by sending CONTEXT_REPLY/repudiated if its ENROL fails. If using ENROL/no-rsp-req, sent with CONTEXT_REPLY, it can achieve the same effect by setting CONTEXT_REPLY/related; CONTEXT_REPLY/completed & ENROL/no-rsp-req means the failure of the enrollment can be ignored - this is only to be allowed if the CONTEXT was atomic.

Details are in draft 0.9.0.4 , in particular in the related group text for CONTEXT & application message and CONTEXT_REPLY & ENROL.
Voted: Conference call, 16 January 2002
Vote result: unanimous consent


Issue 81: Resending ENROL

Status: change agreed (changed 13 Feb 2002)
Date added: 30 Nov 2001
Submitter: Choreology
Category: minor technical
Description:
ENROL currently cannot be resent (with the same identifiers). This seems to be wrong - it can be unambiguously identified as a repeat, and not allowing it makes enrollment more fragile than other actions.
Discussion threads in email archive:    
Announcement, 30 Nov 2001    Peter Furniss, 10 Feb 2002
Proposed solution:

Allow repeat ENROL/rsp-req to be sent from inferior after it has sent it, but not received an ENROLLED (i.e. in state a1)

Allow repeat ENROL/no-rsp-req to be sent from inferior after it has it, (i.e. in state b1)

Add a superior state B2, entered after receiving a second ENROL/rsp/req. Sending ENROLLED returns to B1, cannot send SUPERIOR_STATE (use ENROLLED instead) otherwise identical to B1.

Allow inferior to accept (and ignore) ENROLLED in states where this is now possible.

These changes are included in 0.9.1.3, marked in green and cyan.
Voted: 13 February 2002, unanimous


Issue 82: ENROL related to application message

Status: change agreed (changed 30 Jan 2002)
Date added: 30 Nov 2001
Category: minor technical
Submitter: Choreology
Description:
we don't currently state that an ENROL message can be related to application response. One ought to be able to have an application where the context (almost certainly a CONTEXT/cohesion) is made available, but the first (only ?) specific application message is sent from the inferior-side to the superior-side (i.e. this isn't client-server at all). This would require an ENROL to be related to some applicatin message.
Discussion threads in email archive:    
Announcement, 30 Nov 2001    Peter Furniss, 18 Dec 2001    Peter Furniss, 12 Jan 2002
Agreed solution:
Allow ENROL to be related to application messages. As with CONTEXT and application messages, the meaning of the relation is application-specific.

Details are in section "CONTEXT_REPLY & ENROL & application message (& PREPARED)" in draft 0.9.0.4 , where the meaning is defined as

Meaning: the relation between the BTP messages is as for the preceding groups, The transmission of the application message (and application effects implied by its transmission) has been associated with the Inferior identified by the ENROL and will be subject to the outcome delivered to that Inferior.

In the SOAP binding subsection "Mapping for BTP messages related to application messages", the related messages are stated as CONTEXT and ENROL.
Vote considered: Conference call, 16 January 2002
Vote result: unanimous consent
Supporting Material (for vote 30 January):
This was deferred during the January 16th conference call.

The ID and REF stuff has been removed in 0.9.0.4, but the main text is unchanged from 0.9.0.3

The proposed resolution of the issue affects the SOAP binding in so far as any reference to CONTEXT becomes CONTEXT or ENROL as the messages that can be related to application messages.

As for CONTEXT, the precise meaning of the relationship to application messages is application specific.
Voted: Conference call, 30 January


Issue 83: BTP message related to *part of* application message

Status: change agreed (changed 16 Jan 2002)
Date added: 30 Nov 2001
Submitter: Choreology
Category: minor technical
Description:
In the SOAP bindings, any and all application message in the SOAP-Body is related to the appropriate BTP messages in the SOAP-Header. It is possible to conceive of applications where a compound *application* message has parts that are intended to be in one BT, some in another (almost certainly atoms within the same cohesion).

A relationship between a particular BTP message (CONTEXT or ENROL) and part of an application message could be indicated using the ID and REF mechanisms of XML. There would be significant implications for the application at each end, which has got to sort out which BT applies, but the basic protocol mechanism would be easy to specify.
Discussion threads in email archive:    
Announcement, 30 Nov 2001    Peter Furniss, 18 Dec 2001    Peter Furniss, 12 Jan 2002
Agreed solution:
Do not specify a mechanism to support this - leave it to the application to determine how such multiple relationships are represented. But allow multiple CONTEXTs and ENROLs in a SOAP Header, without stating any implied semantic. Add a note in the subsection "Mapping for BTP messages related to application messages":

Note - An application protocol could use references to the ID values of the BTP messages to indicate relation between BTP CONTEXT or ENROL messages and the application message.

This is included in draft 0.9.0.4
Voted: Conference call, 16 January 2002
Vote result: unanimous consent


Issue 84: What determines one-shot is used

Status: change agreed (changed 16 Jan 2002)
Date added: 30 Nov 2001
Submitter: Choreology
Category: minor technical
Description:
0.9 says that one-shot (ENROL and PREPARED with CONTEXT_REPLY on application response) is a specialisation (senders option) of one-wire, because it is specified that the inferior-side decides if it can do one-shot by matching the binding addresses to the address for the application response.

There are various problems with this - among them, it assumes the service-side has an address for the application response to match against, rather than just a pending http response. Since application request/response is the most likely use of one-shot, this is rather important.

An alternative approach is to assume that the service side knows (by application/configuration) that it should do one-shot replies, regardless of the superior address. ENROL and PREPARED are sent with the CONTEXT_REPLY.

A possible complication is that the Superior's address is different from the reply address for the application (or rather the destination of the CONTEXT_REPLY). However, in this case the receiver of the CONTEXT_REPLY (the client-side interceptor/communicator, probably) will know the superior's address (it can/must be assumed to - since it put the CONTEXT there, that is reasonable) and can forward the ENROL and PREPARED to there. This implies ENROL and PREPARED must be related only to the CONTEXT_REPLY for their transaction.
Discussion threads in email archive:    
Announcement, 30 Nov 2001    Mark Little, 1 Dec 2001    Peter Furniss, 12 Jan 2002
Agreed solution:
(Assumes the proposed solution for Issue 85, that related groupings and the defined procedures are defined.)

The decision to use one-shot is determined by the Inferior (server) side, subject to application and configuration constraint.

Text to implement this is included in draft 0.9.0.4 , in changes in "Compounding messages" in the abstract message section, and in the detailed specification of the related group "CONTEXT_REPLY & ENROL & application message (& PREPARED)".

The answer to the question itself is stated in the last paragraph of the "compounding messages" section:

Whether the "one-shot" mechanism is used is determined by the implementation on the responding (Inferior) side. This may be subject to configuration and may also be constrained by the application or by the binding in use.

Voted: Conference call, 16 January 2002
Vote result: unanimous consent

Issue 85: Relationship by separate container, not containment

Status: change agreed (changed 16 Jan 2002)
Date added: 30 Nov 2001
Category: minor technical
Submitter: Choreology
Description:
Draft 0.9 specifies that relationship between btp messages is represented by containment of one in another. However, this doesn't fit well with most of the btp:btp related cases - CONTEXT_REPLY, ENROL, PREPARED especially. It also requires the relatedness to have a polarity, which isn't always easy to define. All that is actually needed is to define what processing or other semantic implications there are in relating particular types of message, and have a minimal way of expressing that the messages are related.
Suggested solution:
The meaning of each relationship is defined for each legitimate combination on a case-by-case basis in terms of what processing is required

In XML, represent "related" (&) by having an enclosing construct (<btp:related> that contains the related messages as immediate children.
Discussion threads in email archive:    
Announcement, 30 Nov 2001    Peter Furniss, 18 Dec 2001    Peter Furniss, 12 Jan 2002
Agreed solution:
These changes are included in draft 0.9.0.4 , which should be referred to for the details.

Change the first part of "Compounding messages" to define the term "group" for a set of related (&) messages, "bundle" for a set of unrelated messages (i.e. the combination has no semantic significance). State that groups have defined semantics, that only certain combinations of messages can be &-grouped, and that the addressing of such follows specific rules for each group. Bundles are created as desired under the constraint only that the binding address in the target addresses match.

Add a new section "Groups - combinations of related messages" at the abstract message section to define the possible related combinations, and what the particular processing is - i.e. what the semantic significance of the relatedness. Define a syntax for the names of the groups to indicate that some messages may not be present (this just reduces the number of procedures that have to be defined)

Groups are:
CONTEXT & application message
CONTEXT_REPLY & ENROL
CONTEXT_REPLY (& ENROL) & PREPARED / & CANCELLED
CONTEXT_REPLY & ENROL & application message ( & PREPARED)
BEGIN & CONTEXT
BEGUN & CONTEXT

Define a new XML element "relatedgroup" to be the container for groups. Use this in the examples of SOAP binding.

Define the meaning of therelationship between CONTEXT & application message as:

Meaning: the transmission of the application message is deemed to be part of the business transaction identified by the CONTEXT. The exact effect of this for application work implied by the transmission of the message is determined by the application - in many cases, it will mean the effects of the application message are to be subject to the outcome delivered to an enrolled Inferior, thus requiring the enrolment of a new Inferior if no appropriate Inferior is enrolled or if the CONTEXT is for cohesion.

Allow CONTEXT_REPLY & ENROL with both reply-requested and not for the ENROL. Specify the rules to ensure that if the enrol fails, the transaction won't commit (see also proposed solution of Issue 80).
Voted: Conference call, 16 January 2002
Vote result: unanimous consent


Issue 86: Reply address on CONTEXT, target address on CONTEXT_REPLY

Status: change agreed (changed 16 Jan 2002)
Date added: 30 Nov 2001
Category: minor technical
Submitter: Choreology
Description:
There appears to be a need for a reply address on CONTEXT as an abstract message, to be the target address of CONTEXT_REPLY. For one-way application messages and a CONTEXT/atom, the CONTEXT_REPLY must be sent back somewhere.

When CONTEXT is sent in relation to an application request in a request/reply protocol, there normally won't need to be a reply address on the CONTEXT, as the CONTEXT_REPLY will be sent on the application response.
Discussion threads in email archive:    
Announcement, 30 Nov 2001    Peter Furniss, 18 Dec 2001    Peter Furniss, 12 Jan 2002
Agreed solution:
Add reply-address to CONTEXT and target-address to CONTEXT_REPLY.

In abstract message definition of CONTEXT, add "reply-address" as new parameter, with explanation

reply-address the address to which a replying CONTEXT_REPLY is to be sent. This may be different each time the CONTEXT is transmitted – it refers to the destination of a replying CONTEXT_REPLY for this particular transmission of the CONTEXT.

Add "BEGIN and BEGUN" at end of the penulitmate paragraph of CONTEXT definition. (this is just a correction, not directly related to the issue)

In abstract message definition of CONTEXT_REPLY, add parameter "target-address", with explanation:

target-address the address to which the CONTEXT_REPLY is sent. This shall be the “reply-address” from the CONTEXT.

Add the reply-address to CONTEXT and target-additional-information to CONTEXT_REPLY as optionals in XML definitions.
Voted: Conference call, 16 January 2002
Vote result: unanimous consent


Issue 87: Conformance Level

Status: change agreed (changed 1 May 2002)
Date added: 1 Dec 2001
Submitter: Geoff Brown, Oracle
Category: technical
Submitter's identification: # 1
Clarification:
The BTP specification could value from having a "bare minimum" conformance level and a "higher value add" level, this will enable vendors of varying sizes to implement a base level of compliance without having to invest heavily in engineering resources.
Question / Suggested solution:

Minimum Level = Standard ( Atomic )

Advanced Level = Enterprise ( Cohesion, J2EE interlinks, Collapsed HIGH-END TP, etc )

This should reduce the specification ( including business justification ) to an attractive size.
Discussion threads in email archive:    
Announcement, 1 Dec 2001    Peter Furniss, 17 Apr 2002    Vote comment - Bill Cox    Vote comment - Sanjay Dalal
Dependent issue: issue 25 : Clarity needed between atomic and cohesion
First vote solution:
Change the second and third paragraphs of the conformance section to

An implementation may implement the functionality of some roles in a non-interoperable way - usually combining pairs of roles, such as Terminator and Decider. Such an implementation is conformant in respect of the roles it does implement in accordance with this specification.

An implmentation can state which aspects of the BTP specification it conforms to in terms of which Roles it supports. Since most Roles cannot usefully be supported in isolation, tThe following Role Groups can be used to describe implementation capabilities:

After the role groups table, add
The Role Groups occupy different positions within a business transaction tree and thus require presence of implementations supporting other Role Groups:


First vote details:: 3 Apr 2002
First vote result: 3 for, 6 against, 4 abstentions
Agreed solution (second vote):
As for first vote solution, but with a different second paragraph of the conformance section (which was the first paragraph of the first vote solution). This will make the first three paragraphs of the conformance section as follows:

A BTP implementation need not implement all aspects of the protocol to be useful. The level of conformance of an implementation is defined by which roles it can support using the specified messages and carrier protocol bindings for interoperation with other implementations.

An implementation may implement some roles and relationships in accordance with this specification, while providing the (approximate) functionality of other roles in some other manner. (For example, an implementation might provide an equivalent of the control relationships using a language-specific API, but support roles involved in the outcome relationships using standard BTP messages.) Such an implementation is conformant in respect of the roles it does implement in accordance with this specification.

An implementation can state which aspects of the BTP specification it conforms to in terms of which Roles it supports. Since most Roles cannot usefully be supported in isolation, the following Role Groups can be used to describe implementation capabilities:.

The changes after the role groups table are as for the first vote solution (which was included in 0.9.5)
Second vote details: William Z Pope, 23 Apr 2002 (bt-main)
Vote result (second vote): 13 for, 1 opposed

Issue 88: Cohesion vs Atomic

Status: resolved (changed 15 Apr 2002)
Date added: 1 Dec 2001
Submitter's identification: # 2
Submitter: Geoff Brown, Oracle
Category: technical
Clarification:
Our interpretation of Cohesion is similar to "Aggregate" / "Long Running Transactions". Cohesion can therefore be considered a low level underpin for possible ebXML process flows AND/OR multi-chain level process.

Atomic transactions as per the current spec is well understood and this element of BTP spec adds significant value. Cohesion's is very desirable, however the current spec is a little vague.
Question / Suggested solution:
Due to the fact that implementing Cohesions is a nontrivial task, should this aspect be moved to the Enterprise level of the conformance spec ?

If Cohesions are to remain part of the core spec ( i.e. mandatory ) then further detailed explanation of mappings needs to be provided. Vendors who already implement "Cohesions" need much more detailed info on how to map to a BTP implementation.
Discussion threads in email archive:    
Announcement, 1 Dec 2001
Vote result: Resolved by conceptual model text; No comment on default vote ended 11 April


Issue 89: J2EE Inter operability - JMS short circuit

Status: resolved (changed 19 May 2002)
Date added: 1 Dec 2001
Submitter's identification: # 3
Submitter: Geoff Brown, Oracle
Category: technical
Clarification:
Oracle supports the current JSR, however a more precise short-circuit is possible to supplement the existing JSR.

If one acknowledges that JMS is one of the most popular ( i.e. widely deployed ) constructs of J2EE and that asynchronous loose coupling is the obvious way ahead, then the ability to share TRX context from a JMS provider via a well defined XML TYPE is both simple and attractive in that allows tight coupling with a core J2EE process.

The bottom line is that sharing context with a provider ( via XMLTYPE ) makes BTP very attractive and easy to implement.
Question / Suggested solution:
BTP supports JMS XMLTYPE, via an agreed BINARY XML ( W3C ) format which contains TRX context and thus provides a simple and fast bridge between BTP and JMS.
Discussion threads in email archive:    
Announcement, 1 Dec 2001    Peter Furniss, 3 Apr 2002
Resolution:
In Committee Specification 1.0, as agreed at the TC meeting on 16th May 2002 - this area is addressed by the statement in the "deferred topics" transaction coordination migration, and the informative annex A on node state serialisation.

As stated in the resolution approving the Committee Specification (see minutes of Newcastle face-to-face meeting), coordination migration will be further addressed by the TC prior to proposing BTP for OASIS Standard.


Issue 90: Process Flows and TRX switch formats

Status: withdrawn (changed 9 Mar 2002)
Date added: 1 Dec 2001
Submitter's identification: # 4
Submitter: Geoff Brown, Oracle
Category: technical
Clarification:
Keep it simple and concise.

A process flow diagram that shows the state values as one progresses through the process chain is required. This should include when a sub co-ordinator receives/passes TRX control between constructs and when moving between Atomic and Cohesion process flows - especially during mid flow.
Question / Suggested solution:
Agree on state change values ( not just attributes ). Once again this state information needs to be accessible via future bindings.
Discussion threads in email archive:    
Announcement, 1 Dec 2001
Note: Closed at submitter's request, the planned solution for issue 89 : J2EE Inter operability - JMS short circuit covers this


Issue 91: Global state visibility - Cohesions

Status: withdrawn (changed 30 Jan 2002)
Date added: 1 Dec 2001
Submitter's identification: # 5
Submitter: Geoff Brown, Oracle
Category: technical
Clarification:
How is Cohesion state visible ?? As Cohesive transactions passes through application infrastructure, the state needs to be stored in an open address space. The spec HAS to state how this is to be achieved, as this element is a major point of inter operability. One can expect that by the very nature of Cohesive transactions performance is slow ( which is acceptable ).
Suggested solution:
State Maps should be stored in an LDAP v3 repository accessible via JNDI.
Discussion threads in email archive:    
Announcement, 1 Dec 2001

Issue 92: Benchmarking Metrics

Status: withdrawn (changed 9 Mar 2002)
Date added: 1 Dec 2001
Submitter's identification: # 6
Submitter: Geoff Brown, Oracle
Category: technical
Clarification:
The BTP metrics should be defined "functionally" via process flows ( that include state maps WITH state changes ).
Suggested solution:
Withdraw benchmark levels till future date.
Discussion threads in email archive:    
Announcement, 1 Dec 2001
Note: Closed at submitter's request

Issue 93: The Spec level

Status: withdrawn (changed 9 Mar 2002)
Date added: 1 Dec 2001
Submitter's identification: # 7
Submitter: Geoff Brown, Oracle
Category: editorial
Clarification:
The specification currently sits at v0.9 .. which implies very clear, concise definitions that an Architect can advise the business on and an engineer can build from. Is the committee confident that this is the case ?? On reviewing the specification our initial issues were in the double digits.
Suggested solution:
Do not force the spec through as adoption will be less attractive. Opinion is divided if all the elements are required. If time is essential then it is more desirable to focus on a STANDARD specification.
Discussion threads in email archive:    
Announcement, 1 Dec 2001
Note: Closed at submitter's request

Issue 94: Target addressing information may be absent

Status: change agreed (changed 13 Feb 2002)
Date added: 6 Dec 2001
Category: minor technical
Submitter: Jim Webber, HP
Description:
shouldn't the target additional information occur "at most once" rather than "exactly once" ? In (all of) the XML fragments, it looks like this:
  <btp:target-additional-information>
    ...additional address information...
  </btp:target-additional-information>

But should probably look like this:

  <btp:target-additional-information> ?
    ...additional address information...
  </btp:target-additional-information>

Discussion threads in email archive:    
Announcement, 6 Dec 2001
Proposed solution:
As in the XML in draft 0.9.1.2

target-additional-information is optional in the XML for all the messages.
Voted: 13 February 2002, unanimous


Issue 95: fault data for WrongState FAULT

Status: change agreed (changed 28 Feb 2002)
Date added: 11 Dec 2001
Category: minor technical
Submitter: Jim Webber, HP
Description:
In the table on page 60/61 of version 0.9 there is a table which contains fault types and their respective fault data. For the fault type "WrongState" there is no corresponding fault data.

Is this an error? Shouldn't it at least be a free text description perhaps giving some information as to the unexpected state which resulted in the error?
Discussion threads in email archive:    
Announcement, 11 Dec 2001    Tony Fletcher, 12 Feb 2002    Doug Bunting, 27 Feb 2002
Agreed solution:
In the FAULT message definition, in the table of Fault type - Meaning - Fault data, in the row for Wrongstate add in cell for the Fault data column "Free text explanation".
Vote result: 14 for, 1 abstain
Vote ended: 27 Feb 2002


Issue 96: Reply address on SUPERIOR, INFERIOR_STATUS

Status: change agreed (changed 28 Mar 2002)
Date added: 4 Jan 2002
Category: minor technical
Submitter: Pyounguk Cho, IONA (drafted PRF)
Description:
Reply address should be added to the parameter list when reply requested = true

The *_STATUS messages can be sent when the receiving side has no knowledge of the location or identity of the partner. If a reply is needed (it will be the /unknown), the responder needs to know where to send it.
Discussion threads in email archive:    
Announcement, 4 Jan 2002    Peter Furniss, 5 Mar 2002
Proposed solution:
Delete the last paragraph in the section Abstract Messages, Request/response pairs and insert:

Between Superior and Inferior the address of the peer is normally known (from the "superior-address" on an earlier CONTEXT or the "inferior-address" on a received ENROL). However, in some cases a message will be received for a Superior or Inferior that is not known - the state information no longer exists. This is not an exceptional condition but occurs when one side has either not created or has removed its persistent state in accordance with the procedures, but a message has got lost in a failure, and the peer still has state information. The response to a message for an unknown (and logically non-existent) Superior is SUPERIOR_STATE/unknown, for an unknown Inferior it is INFERIOR_STATE/unknown. However, since the intended target is unknown, there is no information to locate the peer, which sent the undeliverable message. To enable the receiver to reply with the appropriate *_STATE/unknown, all the messages between Superior and Inferior have a "senders-address" parameter. If a FAULT message is to be sent in response to message which (as an abstract message) has a "senders-address" parameter, the FAULT message is sent to that address.

Note - Both reply-address and senders-address may be absent when the carrier protocol itself has a request/response pattern. In these cases, the reply or sender address is implicitly that of the sender of the request (and thus the destination of a response)

Add a "sender-address" parameter, with type BTP address to the following messages: ENROLLED, RESIGN, RESIGNED, PREPARE, PREPARED, CONFIRM, CONFIRMED, CANCEL, CANCELLED, CONFIRM_ONE_PHASE, HAZARD, CONTRADICTION, SUPERIOR_STATE, INFERIOR_STATE. The explanation for the parameter is:

sender-address the address from which the <message> is sent. This is an address of the <Superior|Inferior>.

substituting appropriately.

For these messages, where there is a FAULTs paragraph, change the text to "... (sent to "sender-address")

In the XML definitions add to the messages listed above: <code> <btp:sender-address> ...address... </btp:sender-address>

In Carrier Protocol Bindings, Bindings for request/response carrier protocols, add at the end of the third paragraph:

These rules also allow the receiver of a message between Superior and Inferior (in either direction) on a carrier protocol request to send any reply message on the carrier response - the "sender-address" field is implicitly considered to be that of the sender of the carrier request.

In the following Request/response exploitation rules, change the fourth paragraph to:

Within the outcome relationship, apart from ENROL, there is no "reply-address", and the parties normally know each other's "superior-address" and "inferior-address". However, these messages have a "sender-address", which is used when the receiver does not have knowledge of the peer. In this case, the "sender-address" is treated as the "reply-address" of the other messages - if the field is absent in a message on a carrier request, the "sender-address" is implicitly that of the request sender. Any message for the peer (including the three messages mentioned, FAULT but also any other valid message in the Superior:Inferior relationship) may be sent on the carrier response. Apart from this, both sides are permitted to treat the carrier request/response exchanges as opportunities for sending messages to the appropriate destination.

Add a new rule:

d) A BTP actor that has received, on a carrier protocol request, one or more BTP messages or related groups that, as abstract messages, have a "sender-address" parameter but no "reply-address" was supplied and does not have knowledge of the peer address, must bundle the responding BTP message and groups in a btp:messages element and transmit this element on the carrier protocol response to the request that carried the BTP request. If the actor does have knowledge of the peer address it may send one or messages for the peer in the carrier protocol response, regardless of whether the binding address of the peer matches the address of the carrier protocol requestor.

Vote result: 8 for, 2 opposed, 1 abstain
Vote ended: 27 Mar 2002

Issue 97: Version identification on xml namespaces

Status: change agreed (changed 20 Mar 2002)
Date added: 4 Jan 2002
Category: editorial
Submitter: Pyounguk Cho, IONA (drafted PRF)
Description:
The proposed "btp" namespace definition does not appear to provide timestamp or version info.
Discussion threads in email archive:    
Announcement, 4 Jan 2002    Alex Ceponkus, 21 Feb 2002
Proposed solution:
Change the namespace URIs

for the main message schema (currently urn:oasis:names:tc:BTP:xml) to

urn:oasis:names:tc:BTP:1:0:core
for the standard qualifiers schema (currently urn:oasis:names:tc:BTP:qualifiers) to
urn:oasis:names:tc:BTP:1:0:qualifiers

Vote result: 13 for, 0 against
Vote ended: 19 Mar 2002

Issue 98: MIME-Version should not be HTTP header

Status: change agreed (changed 28 Mar 2002)
Date added: 4 Jan 2002
Category: editorial
Submitter: Pyounguk Cho, IONA (drafted PRF)
Description:
In the example, "MIME-Version: 1.0" header must not appear in HTTP header according to
http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211
Discussion threads in email archive:    Announcement, 4 Jan 2002
Proposed solution:
Delete the MIME version line at the head of the example
Vote result: 11 for, 0 opposed, 0 abstain
Vote ended: 27 Mar 2002

Issue 99: PREPARE_INFERIORS and FAULT(InvalidInferior)

Status: change agreed (changed 20 Mar 2002)
Date added: 22 Jan 2002
Category: minor technical
Submitter: Mark Little, HP
Description:
When calling PREPARE_INFERIORS (CONFIRM_TRANSACTION), a list of inferior ids is supplied. Now, if any of these inferiors is invalid, the spec. currently says that the InvalidInferior FAULT is generated. However, that's all it says. This leaves it open to implementation specific interpretation (the list below is not meant to be complete):

(i) I could check all inferiors prior to issuing prepare on any of them and only go ahead if all ids in the list are valid.

(ii) I could simply walk down the list and issue prepare and stop when I get to an invalid id. However, what happens to the inferiors I haven't talked to yet and what do I do with those I have.

(iii) I walk down the list and issue prepare and remember if I see any invalid id. At the end of the list I return the appropriate FAULT.

(iv) modify the status-item field such that it is possible to identify which id was invalid.

Now I have a preference as to which I think we should do, but the real reason for this message is to try to get some agreement on a standard approach that we can put in the specification. (BTW, I think (iv) would be a useful enhancement anyway - if I send a list of 1000 inferior ids and only one of them was invalid it would be good if I could get that id (or list thereof) back on the fault message.)
Discussion threads in email archive:    
Announcement, 22 Jan 2002    Mark Little, 22 Jan 2002 (bt-main)    Peter Furniss, 15 Feb 2002    Peter Furniss, 1 Mar 2002
Proposed solution:

In the description of FAULT, in the table of fault-types change the InvalidInferior row to:

InvalidInferior The "inferior-identifier" in the message or at least one "inferior-identifier"s in an "inferior-list" parameter is not known or does not identify a known Inferior One or more invalid identifiers


In the description of CANCEL_INFERIORS add:

If one or more of the "inferior-identifier"s in the "inferior-list" is unknown (does not correspond to an enrolled Inferior), a FAULT(Invalid-inferior) shall be returned. It is an implementation option whether CANCEL is sent to any of the Inferiors that are validly idenitfied in the "inferiors-list".

In the description of CONFIRM_TRANSACTION add:

If one or more of the "inferior-identifier"s in the "inferior-list" is unknown (does not correspond to an enrolled Inferior), a FAULT/Invalid-inferior shall be returned. The Decider shall not make a confirm decision and shall not send CONFIRM to any Inferior.

In the description of PREPARE_INFERIORS add:

one of the following paragraphs:

CHOICE A:

If one or more of the "inferior-identifier"s in the "inferior-list" is unknown (does not correspond to an enrolled Inferior), a FAULT/Invalid-inferior shall be returned. The Decider shall not send PREPARE to any Inferior.

CHOICE B:

If one or more of the "inferior-identifier"s in the "inferior-list" is unknown (does not correspond to an enrolled Inferior), a FAULT/Invalid-inferior shall be returned. It is an implementation option whether PREPARE is sent to any of the Inferiors that are validly identified in the "inferiors-list".

In the faults lists for CANCEL_INFERIORS, PREPARE_INFERIORS and CONFIRM_TRANSACTION, make the the InvalidInferior line

InvalidInferior – if one or more inferior handles in the inferiors-list is unknown

Vote result: 2 for A, 6 for B, 3 abstained
Vote ended: 19 Mar 2002

Issue 100: Separation of delivery information from payload

Status: change agreed (changed 10 Apr 2002)
Date added: 29 Jan 2002
Submitter: Mark Little, HP
Category: minor technical
History: The discussion on this was originally classifed as part of
issue 78 : Addresses used for identification , but
has been separated. Following description has been extracted from part of continuing discussion
Description:
Firstly I don't believe that issue 78 does talk about the separation of deliver from payload as we've been discussing. This is really a separate issue, but one that needs doing no matter what we resolve to do with addresses and identifiers: the specification should make it clear for each message description what information is payload and what is carrier specific.
Discussion threads in email archive:    Mark Little, 28 Jan 2002    Peter Furniss, 29 Jan 2002    JIM WEBBER, 28 Jan 2002    Mark Little, 29 Jan 2002    Announcement, 29 Jan 2002    Mark Little, 30 Jan 2002    Peter Furniss, 13 Mar 2002    Peter Furniss, 3 Apr 2002
Agreed solution:
At beginning of abstract message section, add
The abstract messages include Delivery parameters that are concerned with the transmission and delivery of the messages as well as Payload parameters directly concened with the progression of the BTP relationships. When bound to a particular carrier protocol and for particular implementation configurations, parts or all of the Delivery parameters may be implicit in the carrier protocol and will not appear in the "on-the-wire" representation of the BTP messages as such. Delivery parameters are defined as being only those parameters that are concerned with the transmission of this message, or of an immediate reply (thus address parameters to be used in repeated later messages and the identifiers of both sender and receiver are Payload parameters). In the tables in this section, Delivery parameters are shown in shaded cells.

Reorder target address, reply address, sender address only in the abstract messages to the end of each table (and reorder description paragraphs), and shade the cells these changes are not shown in draft 0.9.2.4

At the end of the introductory paragraphs to the XML (just before the subhead "addresses), add

The Delivery parameters are shown in the XML with a darker background.
And so shade, reordering the delivery parameters to the end of the message. ( not change marked)

Make same ordering changes in the schema, but do not mark

Add to glossary:

Delivery parameter A parameter of an abstract message that is concerned with the transmission of the message to its target or the transmission of an immediate reply.. Distinguished from Payload parameter.

Payload parameter A parameter of an abstract message that is will be received and processed or retained by the receiving BTP actor. The various identifier parameters are considered Payload parameters . Distinguished from Delivery parameter.
Vote details: 3 Apr 2002
Vote result: 11 for, 0 against, 2 abstentions


Issue 101: Identifiers and addresses in received messages

Status: deferred (changed 13 Mar 2002)
Date added: 30 Jan 2002
Submitter: Doug Bunting, Sun
Category: minor technical
History:
This issue summarises an issue discussed at the 30 January conference call - the discussion was under the agenda item of
issue 78 : Addresses used for identification , but has been distinguished because it seemed it built on the proposed solution to 78, rather than being an alternative. It may also relate to issue 100 : Separation of delivery information from payload . (PRF)
Description:
We discussed issues about locating actors with particular names at significant length during 30 January meeting. The issue is basically "How does an actor receiving a message from a previously unknown source associate the provided identifier with an address (such as for a response message)?" The three proposals were:
  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.

Submitter's comment:
I'd say approach 3 is really orthogonal to the choice between 1 and 2. Either way to provide an explicit name to address binding could be extended by a binding specific implicit list.
Discussion threads in email archive:    Announcement, 30 Jan 2002

Issue 102: Is entity identity modification to be allowed within BTP.

Status: deferred (changed 28 Feb 2002)
Date added: 2 Feb 2002
Submitter: Mark Little, HP
Category: minor technical
Description:
In migration (as with REDIRECT), shall it be possible for the identification of the migrated entity (transaction, superior, inferior) to change, or shall it be required that the same name be retained at each endpoint address
Related issue:
issue 78 : Addresses used for identification
Discussion threads in email archive:    Announcement, 2 Feb 2002    Mark Little, 2 Feb 2002    Mark Little, 6 Feb 2002
Suggestion:
add another message pair:

RENAME/RENAMED

whose sole responsibility is similar to REDIRECT but replaces the identifier an actor was known about with another.
Agreed solution:
Defer until after 1.0
Vote result: 13 for, none opposed
Vote ended: 27 Feb 2002


Issue 103: CONTEXT used only with application msgs, not with BEGIN, BEGUN

Status: deferred (changed 18 Mar 2002)
Date added: 3 Feb 2002
Submitter: Jim Webber, HP
Category: minor technical
Description:
1. Make the context a pure application-level message, i.e. by delegating its creation to the intialiser.

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.
Discussion threads in email archive:    
Announcement, 3 Feb 2002    JIM WEBBER, 2 Feb 2002    Peter Furniss, 13 Mar 2002
Proposed solution:
Defer to after 1.0


Issue 104: RESIGN, disruption and CONFIRM_ONE_PHASE

Status: change agreed (changed 13 Feb 2002)
Date added: 8 Feb 2002
Category: minor technical
Submitter: Peter Furniss, Choreology
Description:
The 0.9 state tables omit the possibility of a failure (disruption) at the Superior after receiving RESIGN/rsp-req causing a reversion to the active (B1) state. This inevitably can occur, since there is a time window between the arrival of the message and the implementation doing anything about it.

This would not matter (it could be treated as just the loss of the RESIGN message), except that the same state (C1) is also entered if CONFIRM_ONE_PHASE crosses with RESIGN/rsp-req. The 0.9 state tables require that RESIGNED is still sent by the superior, and the CONFIRM_ONE_PHASE is effectively ignored by the Inferior.

However, the requirement to send RESIGNED in this case is quite unnecessary. It would be much simpler to say that RESIGN/rsp-req is "answered" by receipt of CONFIRM_ONE_PHASE and vice versa. (In fact this means the whole transaction has evaporated and there weren't any changes applied anywhere.)
Proposed solution:
Allow transition C1:disruption -> B1

Change S1:receive RESIGN/rsp-req to -> Z

Change c1:receive CONFIRM_ONE_PHASE to -> z
Discussion threads in email archive:    
Announcement, 8 Feb 2002
Note:
These changes are included in 0.9.1.3, marked in brown.
Voted: 13 February 2002, unanimous


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

Status: deferred (changed 13 Mar 2002)
Date added: 22 Feb 2002
Submitter: Mark Little, HP
Category: minor technical
Description:
In a traditional transaction system (and presumably for atoms), if I issue a prepare and get back cancel/readonly from all participants, I don't have to send anything else to that transaction because I know it has finished. With cohesions, the situation is different. In some cases I'd like implementations to be able to free up resources held by the coordinator implementation immediately simply because there won't be any other registrations and the application shouldn't have to explicitly terminate such a cohesion which now has no members.
Suggested solution:
Have a standard qualifier such that, if following PREPARE_INFERIORS and/or CANCEL_INFERIORS all the current inferiors have either cancelled or resigned gone away, then the cohesion is finished, and replies with TRANSACTION_CANCELLED. Default is not (CANCEL_TRANSACTION would be required).
Discussion threads in email archive:    
Mark Little, 20 Feb 2002    Announcement, 22 Feb 2002

Issue 106: Free text for all FAULTs

Status: change agreed (changed 28 Mar 2002)
Date added: 12 Mar 2002 (initial status deferred)
Submitter: Doug Bunting, Sun
Category: minor technical
Arising from:
issue 95 : fault data for WrongState FAULT
Description:
I would much prefer free text explanations were directly supported by the FAULT message. That would reserve fault-data for additions specific to a fault type and allow additional text no matter what the problem. My preferred resolution would add a free-text parameter (or some such) to the FAULT message and remove "Free text explanation" from the fault-data column wherever specific material isn't required.
Discussion threads in email archive:    Doug Bunting, 27 Feb 2002    Announcement, 12 Mar 2002
Proposed solution:
Add a new parameter to FAULT "fault-text", with explanation:

fault-text Free text describing the fault or providing more information. Whether this parameter is present, and exactly what it contains are an implementation option.

Where "fault-data" is currently "Free text explanation", change it to "None"

Make the same changes in the XML
Vote result: 11 for, 0 opposed, 0 abstain
Vote ended: 27 Mar 2002


Issue 107: Reply to CONFIRM_TRANSACTION if all is ok

Status: change agreed (changed 10 Apr 2002)
Date added: 12 Mar 2002 (initial status deferred)
Submitter: Peter Furniss, Choreology
Arising from:
issue 50 : Default parameter values
Category: editorial
Description:
The abstract message definition says does not say what happens after CONFIRM_TRANSACTION if report_hazard is true and nothing goes wrong, though it does detail all the other cases.

There isn't any equivalent text for CANCEL_TRANSACTION.
Agreed solution:
Add in the definition of CONFIRM_TRANSACTION

If "report-hazard" was "true", TRANSACTION_CONFIRMED shall be sent to the "reply-address" after CONFIRMED has been received from each Inferior in the confirm-set and CANCELLED or RESIGN from each and any Inferior not in the confirm-set.
--------------------- Add in the definition of CANCEL_TRANSACTION
If "report-hazard" was "false", a TRANSACTION_CANCELLED message shall be sent to the "reply-address".

If "report-hazard" was "true" and any HAZARD or CONFIRMED message was received, an INFERIOR_STATUSES reporting the status for all Inferiors shall be sent to the "reply-address".

If "report-hazard" was "true", TRANSACTION_CANCELLED shall be sent to the "reply-address" after CANCELLED or RESIGN has been received from each Inferior.


Discussion threads in email archive:    Doug Bunting, 27 Feb 2002    Announcement, 12 Mar 2002    Peter Furniss, 2 Apr 2002
Vote details: 3 Apr 2002
Vote result: 11 for, 1 against, 1 abstentions

Issue 108: Participant and service identification

Status: change agreed (changed 1 May 2002)
Date added: 12 Mar 2002 (initial status deferred)
Category: minor technical
Submitter: Mark Little, HP
Note:
The proposed solution is a fix to a bug that became apparent in considering this issue.
Description:
Basically, in a traditional transaction system users don't see participants they see services or objects. What participants are enlisted with a transaction on behalf of those services and objects isn't really of interest to the user. When it comes to commit or rollback the transaction, it acts on the transaction and not on the individual participants.

Now in BTP that's still the case if I work purely with atoms. However, in the cohesive world, we're in a completely different ball park . Now the "user" has to know explicitly what the participants are and how they are tied to services. Otherwise, it can't use business logic to say "cancel that insurance quote and prepare that one". How does the "user" get this information when all it typically sees is the mechanisms to begin and end a cohesion? When an invocation is made within the scope of a cohesion+atom then the user will have to remember the atom id. But if the invocation is made within a top-level cohesion (no atom) then the user will need to somehow keep track of what participants were enrolled for each service invocation. Otherwise, if the user simply asks "what are the participants" (e.g., via a statuses message) it has no way of knowing that participant X was for service Y.

Now if memory serves, the original proposed solution to this was that participant identifiers could contain service identifying text, e.g., "TaxiService:1234". OK, but this service identification needs to be unique too (obviously). If participants can only be used within atoms then this becomes less of an issue, but I'm not keen on that restriction.

The current specification doesn't mention this problem at all and paints a fairly rosey picture that cohesions can be used out-of-the-box and are going to simplify our lives. If I can't identify which participants to cancel/prepare/confirm then this isn't going to happen. So, I think whatever we decide (and decide we must) we need to put appropriate text in the specification. Otherwise I think people will stick with atoms or end up doing things in a proprietary manner which then breaks one of the basic principles behind BTP (interoperability).
Discussion threads in email archive:    
Mark Little, 27 Feb 2002    Announcement, 12 Mar 2002    Alastair Green, 6 Mar 2002    Peter Furniss, 3 Apr 2002    Peter Furniss, 12 Apr 2002 (bt-main)    Peter Furniss, 19 Apr 2002    Vote comment - Bill Cox
Change agreed in first vote:
In the description of CONTEXT_REPLY, at the end of the first paragraph:

CONTEXT_REPLY is used in some of the related groups to allow BTP messages to be sent to a Superior with an application message.
Add to the list of completion-status values: incomplete = Further enrolments are possible (used only in related groups with other BTP messages) In the description of the CONTEXT_REPLY & ENROL related group, change "completed" to "incomplete" Align the XML with these changes
First vote details:: 3 Apr 2002
First vote result: 7 for, 4 against, 0 abstentions
Agreed solution (second vote):
In the model section "Control of Inferiors", change the latter part as shown:

For this control of the Inferiors to be useful, the Terminator application element will need to be able to associate particular parts of the application work with each Inferior. This can be achieved by various means. Taking the case of an application element controlling a Cohesion Composer:

  1. The application element can create an Atom Sub-coordinator as an immediate Inferior of the Cohesion Composer and propagate the Sub-coordinator’s CONTEXT associated with application messages concerned with the particular part of the application work; any Inferiors (however many there may be) enrolled with Sub-coordinator can be assumed to be responsible for (some of) that part of the application, and the Terminator application element can just deal with the immediate Inferior of the Composer that it created.
  2. The application element can propagate the Composer’s own CONTEXT, and the receiving application element can create its own Inferior (or Inferiors) which will be responsible for some part of the application, and send ENROL(s) to the Composer (as Superior). Application messages concerned with that part of the application are associated, directly or indirectly, with the each ENROL, and the Terminator application element can thus determine what the each Inferior is responsible for.

In both cases, the means by which the application message and the BTP CONTEXT or ENROL are associated is are ultimately application-specific, and there are several ways this can be done.

NOTE -- For example, a service receiving an invocation associated with a cohesion CONTEXT, but where the application design meant that there would be no more than one Inferior enrolled as a result of that invocation, could be required to include information identifying the service and the invocation in the “inferior-name” qualifier on the consequent ENROL. These qualifiers would be visible to the Terminator on INFERIOR_STATUSES, allowing the Terminator to determine which “inferior-identifiers” to include in the “inferiors-list” parameter of the CONFIRM_TRANSACTION which defines which Inferiors are to be confirmed. Among other alternatives, the “inferior-identifier” itself could be a field of the application response – this would also be applicable where there could be multiple Inferiors enrolled as a consequence of one invocation for the Terminator to choose between.

Second vote details: William Z Pope, 23 Apr 2002 (bt-main)
Vote result (second vote): 14 for, none opposed

Issue 109: SOAPAction HTTP header must be present

Status: change agreed (changed 10 Apr 2002)
Date added: 28 Mar 2002
Submitter: Anne Manes, Systinet
Category: minor technical
Description:
Based on 18 March 2002 revision 0.9.2.3.

Lines 4937-4939 say:

"The SOAPAction HTTP header shall be omitted when the SOAP message carries only BTP messages in the SOAP Body."

In SOAP 1.1, the SOAPAction HTTP Header is required.
Agreed solution:
The SOAPAction HTTP header shall contain no value when the SOAP message carries only BTP messages in the SOAP Body.
Discussion threads in email archive:    
Anne Thomas Manes, 23 Mar 2002
Vote details: 3 Apr 2002
Vote result: 9 for, 0 against, 4 abstentions


Issue 110: SOAP/HTTP binding should include HTTP/SSL

Status: deferred
Date added: 12 Apr 2002 (initial status deferred)
Category: minor technical
Description:
The "soap-http-1" and "soap-attachments-http-1" bindings should allow use of HTTP/SSL (https). This is currently precluded by the definition of the binding address format, which says it must be an HTTP URL.
Suggested solution:
Change the definition of binding address format for "soap-http-1" to
Binding address format: shall be a URL, of scheme http or https.

Discussion threads in email archive:    
Announcement, 12 Apr 2002
Submitter: Peter Furniss, Choreology

This file last updated 15:33 19 May 2002 (UTC)