http://docs.oasis-open.org/ws-tx/issues/ Date: 2007/04/11 Revision: 41 spec schema soap wsdl policy rddl all Review Active Deferred Dropped Pending Done Resolved Closed The description of Status is incorrect. The spec currently describes the receipt of the Status message as causing the target service to return a QName. My interpretation of the spec is that, in fact, nothing is returned when a Status message is received - it is a response to a getStatus message, i.e. Status is to getStatus what Closed is to Closing. ws-ba spec editorial Andy Wilkinson Andy Wilkinson The text on lines 213-215 to be replaced to accurately describe Status. I propose: "Received in response to a getStatus request. The message includes a QName indicating the state of the Coordinator or Participant to which the request was sent." The proposed resolution was accepted during March 14, 2006 F2F meeting. Precisely specify normative behaviour of CreateCoordinationContext against existing (superior) context ws-coord spec design Alastair Green Alastair Green Sub-issue a). Editorial work required to clarify example, and accompanying figure, and to create a section that describes the model and normative operation of sub-coordination. Sub-issue b). Remove any normative reference to subcoordinator identifier inheritance in WS-Coordination. Sub-issue c). Remove any normative statement relating to sameness of superior and sub-coordinator coordination types or protocols. Sub-issue d). Remove any normative statement relating to the timing of sub-coordinator registration, other than to state that the sub-coordinator must be registered to take part in activity completion. ACTION: Alastair to post 4 new issues to clarify the discussion. Dec 15, 2006 call New issues 18, 19, 20 and 21 opened to represent issue 2 sub-issues. This issue was closed with no action on Jan 12, 2006 call. i018 i019 i020 i021 Faults in WS-C should be divided into two categories: those which apply to the process of context creation and registration (or which apply to the misuse of the conversational channel created by registration), and those which are basic faults available to all coordination protocols. ws-coord spec schema design Alastair Green Alastair Green Named faults should be added to permit the ActivityService and RegistrationService to repudiate legal messages that cannot be processed at run-time. Faults that apply to the behaviour of some but not all conceivable coordination protocols should be defined by the specification of each individual coordination protocol, and should not be specified in WS-Coordination. Faults that apply to the interactions of application elements (as opposed to the interactions of Coordinators and Participants, viewed as roles in a coordination protocol), e.g. those relating to potential unwillingness or incapacity to use a propagated context, should not be specified in WS-Coordination. i004 i005 i006 i008 i012 i013 Activation Service should be able to communicate inability to create a context. ws-coord spec schema design Alastair Green Alastair Green 1) Insert new Fault description (order in section an editorial matter) as follows: 4.x Cannot Create Context This fault is sent by the Activation Service to the sender of a CreateCoordinationContext to indicate that a context could not be created. Properties: [Code] Sender [Subcode] wscoor:CannotCreateContext [Reason] CoordinationContext could not be created. [Detail] unspecified 2) Add new enumeration to schema type ErrorCodes: <xsd:enumeration value="wscoor:CannotCreateContext"/> Proposed resolution accepted on TC Telcon i003 i005 Registration Service should be able to communicate inability to register a participant. ws-coord spec schema design Alastair Green Alastair Green 1) Insert new Fault description (order in section an editorial matter) as follows: 4.x Cannot Register Participant This fault is sent by the Registration Service to the sender of a Register to indicate that the Participant could not be registered. Properties: [Code] Sender [Subcode] wscoor:CannotRegisterParticipant [Reason] Participant could not be registered. [Detail] unspecified 2) Add new enumeration to schema type ErrorCodes: <xsd:enumeration value="wscoor:CannotRegisterParticipant"/> Proposed resoltuion accepted on TC Telcon i003 i004 NoActivity fault is not basic to all conceivable coordination protocols. ws-coord spec schema design Alastair Green Alastair Green Remove ll. 443-450 of the specification. Remove l. 104 of the schema document. Proposed resolution accepted on TC Telcon i003 i005 Register/RegisterResponse should be retriable exchange. ws-coord ws-ba spec design Alastair Green Alastair Green Insert the following text in WS-Coordination spec, Section 3.2 "Registration Service" immediately following current l. 294 "[New paragraph]The requester MAY send a Register message for a given Participant more than once, and the underlying transport could deliver the Register message more than once. On receipt of a Register message for a given Participant, which has already been processed succesfully, the Registration Service MUST send to the requester a RegisterResponse containing the same CoordinationProtocolService element (Endpoint Reference for Participant to Coordinator protocol messages) as that contained in all previous RegisterResponses generated by the Registration Service which relate to the Participant's request to register for this activity. [New paragraph]" See message Changes to WS-Coordination Add the following to WS-C, after line 307 (at the end of section 3.2): "A Registration service is not required to detect duplicate Register requests and may treat each Register message as a request to register a distinct participant. A participant MAY send multiple Register requests to a Registration service. For example, it may retry a Register request following a lost RegisterResponse, or it may fail and restart after registering successfully but before performing any recoverable work. If a participant sends multiple Register requests for the same activity, the participant MUST be prepared to correctly handle duplicate protocol messages from the coordinator. One simple strategy for accomplishing this is for the participant to generate a unique reference parameter for each participant Endpoint Reference that it provides in a Register request. The manner in which the participant handles duplicate protocol messages depends on the specific coordination type and coordination protocol." No changes are required to WS-AT The state table already illustrates the correct behaviour for the 2 cases: lost RegResp. Should allow forward progress. See "participant view" state table for handling of duplicate protocol messages:[event=Prepare, state=PreparedSuccess] -> "Resend Prepared" [event=Commit, state=None] -> "Send Committed" reinfection after failure. Should cause failure. See "participant view" state table for participant handling of protocol messages for an unknown/forgotten activity: [event=Prepare, state=None] -> "Send Aborted" Changes to WS-BA One correction and one clarification required in WS-BA: (i) Correction: In Appendix B, Table C3 "CoordinatorCompletion - protocol messages received by Participant", change cell [event=Complete, state=None] from "Ignore/Ended" to "Send Fault/Ended", (ii) Clarification: Add the following text after line 218 (description of the "GetStatus" message): "A coordinator that is waiting for a participant to initiate the BusinessAgreementWithParticipantCompletion might use this message to confirm that the participant is in one of the expected states: "wsba:Active" or "wsba:Completed". If the participant has failed and forgotten the activity the Status response will be "wsba:Ended", which must be treated by the coordinator as a failure condition. Proposal 2 accepted on TC Telcon. i008 i009 i014 AlreadyRegistered fault is redundant if participant registration is treated as retriable. ws-coord spec schema design Alastair Green Alastair Green Remove ll. 460-468 of the specification. Remove l. 99 of the schema document. Proposed resolution accepted on TC Telcon i003 i014 Why not eliminate use of request-reply MEP, thereby simplifying all three specs? ws-coord ws-at spec design Alastair Green Alastair Green Move all definitional wording relating to message types, MEPs, and rules relating to use of WS-Addressing headers, to WS-Coordination spec, and excise appropriate parts of WS-AT Section 9. Insert new section in WS-Coordination called "Message Exchanges and Use of WS-Addressing Headers". Insert text to the effect that: "Messages used in WS-Coordination, and in coordination protocols whose endpoint agents (Coordinators and Participants) exchange addresses using the WS-Coordination Registration Service, generally fall into three types: notifications, terminal notifications, and faults. Notification messages contain a wsa:ReplyTo header; terminal notifications MUST NOT contain a wsa:ReplyTo header. [New paragraph] Two parties may send and resend notifications, faults and terminal notifications to each other to achieve the full exchange of messsages demanded by a particular specified protocol, i.e. to help execute and terminate exchanges that will ultimately succeed despite failures or duplicate message deliveries resulting from use of unreliable transports or from use of retries. Such exchanges are known as retriable exchanges. Use of retriable exchanges in conjunction with recoverable endpoint agents allows the creation of reliable exchanges. WS-Coordination message exchanges, and coordination protocol specifications which use and reference WS-Coordination, are generally expected to operate over unreliable transports, and to define adequate retriable exchanges to assure protocol operation in the face of such transports. They may in addition define pre-failure state persistence and post-failure state recovery rules to assure protocol operation in the face of endpoint agent failures. "[New paragraph]Each individual protocol must define its particular valid message sequences, including which messages are terminal notifications. Terminable exchanges consist of a retriable conversational sequence of one or more notification messages, ended by the receipt of a final terminal notification by one party. The receiver of a terminal notification must not send any further messages to the sender of a terminal notification relating to the particular exchange. Interminable exchanges between two parties permit one party to resend notification messages to the other, even if they have received a notification message which is a valid response to an earlier send. Exchanges which allow one party learn of the state of the other can often usefully be defined as interminable exchanges." These definitions, or improved/more precise wording of the same intent coming from the editors, can be referenced elsewhere in WS-Coordination, and in WS-AT and in WS-BA. See document. See message. Proposed resolution 2 accepted on TC Telcon. i007 i010 i011 Define Completion protocol as "interminable". ws-at spec design Alastair Green Alastair Green Insert into Section 9 text stating: "The Completion protocol messages Commit, Rollback, Committed and Aborted are all notification messages. Commit and Rollback can be sent to by the Initiator to the Coordinator even if one of Committed or Aborted has already been received by the Initiator. The exchanges Commit - Committed | Aborted, and Rollback - Committed | Aborted are interminable, therefore." It is possible for the transaction originator to register as a participant in order to find out the outcome of the transaction. The issue was closed with no action, during March 14, 2006 F2F meeting. i007 i009 i011 Define BA coordination protocols as "terminable", specifying which messages are terminal notifications. ws-ba spec design Alastair Green Alastair Green Insert a new section mirroring the classification of WS-AT messages, such that the coordination protocol messages Exited, Cancelled, Closed and Compensated are terminal notifications, and the other non-fault messages are notifications. The resolution to issue 9 addresses this issue. This issue was closed with no action during March 14, 2006 F2F meeting. i007 i009 i010 Means of context propagation by application cannot be prescribed by WS-Coordination. ws-coord spec editorial Alastair Green Alastair Green Replace the paragraph (ll. 135-139), which reads: "The CoordinationContext is a Context type that is used to pass Coordination information to parties involved in a coordination service. CoordinationContext elements are placed within application messages. Conveying a context on an application message is commonly referred to as flowing the context. A CoordinationContext provides access to a coordination registration service, a coordination type, and relevant extensions." with the paragraph: "The CoordinationContext is used by applications to pass Coordination information to parties involved in an activity. CoordinationContext elements are propagated to parties which may need to register Participants for the activity, using application-defined mechanisms -- e.g. as a header element of a SOAP application message sent to such parties. (Conveying a context in an application message is commonly referred to as flowing the context.) A CoordinationContext provides access to a coordination registration service, a coordination type, and relevant extensions." Replace the statement (ll. 177-178) "When an application propagates an activity using a coordination service, applications MUST include a Coordination context in the outgoing message." with the following sentence: "An application may propagate a CoordinationContext element as a child element of the Body, or of the Header, of an application SOAP message. [delete new paragraph and run on to next sentence]" (1) Accept first replacement paragraph (lines 135-139) as suggested in the intial proposal. (2) Reject second replacement proposal in the intial proposal but change the existing text to remove the word "outgoing" in line 178. Proposal 2 was made and accepted on TC Telcon. i013 ContextRefused fault relates to application protocol behaviour which should not be specified by WS- Coordination. ws-coord spec schema design Alastair Green Alastair Green Remove ll. 451-459 of the specification. Remove l. 100 of the schema document. Proposed resoltuion accepted on TC Telcon i003 EPR comparison to establish identity of participants is problematic. Additional mechanism required to identify Participants. ws-coord spec schema design Alastair Green Peter Furniss There are three possible resolutions that come to mind. One is to allow a brand-new IRI element in Register, e.g. /Register/Identifier, which mirrors the /CoordinationContext/Identifier. The other is to define an extension IRI element, for WS-Coordination, that can be added into the RS EPR (/CoordinationContext/RegistrationService), to identify the Coordinator; and into the C-P EPR (the /Register/ParticipantProtocolService) to identify the Participant. This would be permitted, as we see it, by the WS-Addressing statement quoted earlier: "However, note that it is possible for other specifications to provide a comparison function that is applicable within a limited scope." The third is to ask WS-Addressing to provide a standard comparable element in the EPR. This seems extremely unlikely, as the move to Candidate Recommendation from Submisssion removed the capacity to compare EPRs. EPR comparisons cannot be used reliably. This issue was dropped with no action during March 14, 2006 F2F meeting. i007 i008 Replace namespace and action URIs of the form href="http://schemas.xmlsoap.org/ws/2004/10/">http://schemas.xmlsoap.org/ws/2004/10/... with URIs that follow OASIS namespace guidelines. ws-coord ws-at ws-ba all design Ian Robinson Ian Robinson In the following URIs, replace http://schemas.xmlsoap.org/ws/2004/10/... with http://docs.oasis-open.org/wstx/2005/11/... http://schemas.xmlsoap.org/ws/2004/10/wscoor ws-c line 82 http://schemas.xmlsoap.org/ws/2004/10/wscoor/Register ws-c line 87 http://schemas.xmlsoap.org/ws/2004/10/wscoor/fault ws-c line 373 http://schemas.xmlsoap.org/ws/2004/10/wsat ws-at line 16 http://schemas.xmlsoap.org/ws/2004/10/wsat/Commit ws-at line 21 http://schemas.xmlsoap.org/ws/2004/10/wsat/Completion ws-at line 106 http://schemas.xmlsoap.org/ws/2004/10/wsat/Volatile2PC ws-at line 138 http://schemas.xmlsoap.org/ws/2004/10/wsat/Durable2PC ws-at line 145 http://schemas.xmlsoap.org/ws/2004/10/wsat/fault ws-at line 279 http://schemas.xmlsoap.org/ws/2004/10/wsba ws-ba line 78 http://schemas.xmlsoap.org/ws/2004/10/wsba/Complete ws-ba line 83 http://schemas.xmlsoap.org/ws/2004/10/wsba/AtomicOutcome ws-ba line 125, 141, 253 http://schemas.xmlsoap.org/ws/2004/10/wsba/MixedOutcome ws-ba line 126,142, 257 http://schemas.xmlsoap.org/ws/2004/10/wsba/ParticipantCompletion ws-ba line 162 http://schemas.xmlsoap.org/ws/2004/10/wsba/CoordinatorCompletion ws-ba line 230 http://www.msn.com See message. Proposal 2 accepted on TC Telcon. In order to coordinate long running interactions, it is necessary to tolerate failures and recovery situations within the scope of an activity (long running activity). Once a participant is registered with a coordinator, the current specification implicitly mandates that recovery requires it to come back up on the same EPR in order that the coordinator can subsequently drive it through whatever protocol is used (e.g., 2PC). However, recovery on the same EPR cannot be guaranteed and is at best an implementation choice. Failure to recover on the same EPR will ultimately lead to more coordinated activities terminating in a failure state (e.g., aborting) because participants cannot be reached, even if they failed and recovered prior to the start of execution of the coordinator's protocol. ws-coord spec schema design Mark Little Mark Little That we add a ReplaceParticipant operation that allows a registering service to instruct the coordinator service to replace one EPR with another EPR. Because EPRs are not currently comparable, a resolution of issue 7 or 14 is relevant to this issue. No need to specify a mechanism for recovery, since it is implementation specific. This issue was closed with no action during March 14, 2006 F2F meeting. Inconsistencies in how contributed specifications were mapped to the OASIS template. ws-coord ws-at ws-ba spec editorial Colleen Evans Colleen Evans 1. Use a consistent title format. Suggest: Web Services xxx (WS-xxx) Working Draft 1.1, [date] 2. Remove duplicate appendix listings. 3. Add the composable architecture section to BA between 1.1 and 1.2. 4. Remove distinction between normative and non-normative references in BA at this stage (we can add that distinction to later drafts if desired). 5. Move AT references up to be the final sub-section in 1 (1.5) 6. Add original spec authors and acknowledged individuals to the acknowledgement sections of AT and BA. Proposed resolution accepted on TC Telcon Precisely specify normative behaviour of CreateCoordinationContext against existing (superior) context. ws-coord spec design Alastair Green Alastair Green Editorial work required to clarify example, and accompanying figure, and to create a section that describes the model and normative operation of sub-coordination. See message. Refer to document. The document has change markings, beginning in section 3, line 182. Proposal 2 accepted on TC Telcon. i002 i019 i020 i021 Avoid any normative reference to subcoordinator identifier inheritance. ws-coord spec design Alastair Green Alastair Green Remove any normative reference to subcoordinator identifier inheritance in WS-Coordination. See message. Refer to document. The document has change markings, beginning in section 3, line 182. Proposal 2 was accepted on TC Telcon. i002 i018 i020 i021 Avoid normative statements on sameness of super- and sub-coordinator coordination types. ws-coord spec design Alastair Green Alastair Green Remove any normative statement relating to sameness of superior and sub-coordinator coordination types or protocols. See message. Refer to document. The document has change markings, beginning in section 3, line 182. Proposal 2 was accepted on TC Telcon. i002 i018 i019 i021 Avoid normative statements on timing of sub-coordinator registration. ws-coord spec design Alastair Green Alastair Green Remove any normative statement relating to the timing of sub-coordinator registration, other than to state that the sub-coordinator must be registered to take part in activity completion. See message. Refer to document. The document has change markings, beginning in section 3, line 182. Proposal 2 was accepted on TC Telcon. i002 i018 i019 i020 Lines 179-180 outline a condition where mustUnderstand is required, however the current text does not reflect the normative nature of this requirement. ws-coord spec editorial Colleen Evans Colleen Evans Replace the text: "When a context is exchanged as a SOAP header, the mustUnderstand attribute must be present and its value must be true." With: "When a context is exchanged as a SOAP header, the mustUnderstand attribute MUST be present and its value MUST be true." Proposed resolution accepted on TC Telcon. The definition of expires is arguably incomplete and as a result unclear. The unit is only defined w.r.t CreateCoordinationContext in the WS-C spec where it is specified as milliseconds, no unit is defined for the inclusion of expires in a CoordinationContext. The period to which expires refers is not specified anywhere. The example in the WS-C spec (line 153) where it is 3000 would appear to imply that it is a period of time sincethe creation or import of the coordination context however the text in the AT and BA specs describes expires as specifying a "point in time" which could be interpreted as implying expires represents a period since the epoch. ws-coord ws-at ws-ba spec editorial Andy Wilkinson Andy Wilkinson WS-Coordination: Add a new paragraph within section 2 to compliment the description on lines 236 and 237 that reads: Expires is an optional element which represents the remaining expiration for the CoordinationContext as an unsigned integer in milliseconds. WS-AT: Amend lines 76 - 79 by replacing "the earliest point in time at which" with "the period after which" such that they read: A coordination context may have an Expires attribute. This attribute specifies the period after which a transaction may be terminated solely due to its length of operation. From that point forward, the transaction manager may elect to unilaterally roll back the transaction, so long as it has not transmitted a Commit or a Prepared notification. WS-BA: Amend lines 134 - 136 by replacing "the earliest point in time at which" with "the period after which" such that they read: A coordination context may have an Expires attribute. This attribute specifies the period after which a long-running activity may be terminated solely due to its length of operation. A participant could terminate its participation in the long running activity using the Exit protocol message. WS-Coordination: Add a new paragraph within section 2 to compliment the description on lines 236 and 237 that reads: Expires is an optional element which represents the remaining expiration for the CoordinationContext as an unsigned integer in milliseconds to be measured from the point at which the context was first received. WS-AT: Amend lines 76 - 79 by replacing "the earliest point in time at which" with "the period after which" and defining the point from which expiration is measured such that they read: A coordination context may have an Expires attribute. This attribute specifies the period, measured from the point in time at which the context was first received, after which a transaction may be terminated solely due to its length of operation. From that point forward, the transaction manager may elect to unilaterally roll back the transaction, so long as it has not transmitted a Commit or a Prepared notification. WS-BA: Amend lines 134 - 136 by replacing "the earliest point in time at which" with "the period after which" and defining the point from which expiration is measured such that they read: A coordination context may have an Expires attribute. This attribute specifies the period, measured from the point in time at which the context was first received, after which a long-running activity may be terminated solely due to its length of operation. A participant could terminate its participation in the long running activity using the Exit protocol message. Proposal 2 was accepted during March 14, 2006 F2F meeting. WS-AT specification: Section 1.6 Non-normative References, PDF line number 50, hyperlink for text 'Web Services Coordination (WS-Coordination)' currently points to an incorrect link http://schemas.xmlsoap.org/ws/2004/10/coord. The correct link is http://schemas.xmlsoap.org/ws/2004/10/wscoor. WS-BA specification: Section 1.6 Non-normative References, PDF line number 103, the text 'Web Services Coordination (WS-Coordination)' should link to http://schemas.xmlsoap.org/ws/2004/10/wscoor. WS-Coordination specification: Section 1.8 References, PDF line number 114: The text 'Web Services Atomic Transaction (WS-AtomicTransaction)' should link to http://schemas.xmlsoap.org/ws/2004/10/wsat. The links in the References section of all the three generated PDF documents are not navigable. ws-coord ws-ba ws-at spec editorial Ram Jeyaraman Ram Jeyaraman WS-AT specification: Section 1.6 Non-normative References, PDF line number 50, hyperlink for text 'Web Services Coordination (WS-Coordination)' currently points to an incorrect link http://schemas.xmlsoap.org/ws/2004/10/coord. The correct link is http://docs.oasis-open.org/ws-tx/wscoor/2006/03. WS-BA specification: Section 1.6 Non-normative References, PDF line number 103, the text 'Web Services Coordination (WS-Coordination)' should link to http://docs.oasis-open.org/ws-tx/wscoor/2006/03. WS-Coordination specification: Section 1.8 References, PDF line number 114: The text 'Web Services Atomic Transaction (WS-AtomicTransaction)' should link to http://docs.oasis-open.org/ws-tx/wsat/2006/03. The links in the References section of all the three generated PDF documents should be navigable. Proposed resolution accepted on TC Telcon. On the first page, under Status, the latest WS-BA draft states: "This document is published by the WS-Tx TX as a "working draft". ws-ba spec editorial Mark Little Tom Freund Should be "This document is published by the WS-TX TC as a "working draft"." The proposed resolution was accepted during March 14, 2006 F2F meeting. The resolution is already incorporated in the cd-01 draft. The WS-Coordination, WS-AT and WS-BA specifications should include an inline (embedded) copy of the corresponding WSDL and XSD in the Appendix section. This will ensure that a printed copy of the specification will contain the prescribed definitions. For example, please refer to the RM specification http://www.oasis-open.org/committees/download.php/16851/wsrm-1.1-spec-wd-10.pdf, PDF line numbers 618 and 1174. ws-coord ws-at ws-ba spec editorial Ram Jeyaraman Ram Jeyaraman Include an inline copy of the XSD and WSDL in the specification. The Schema and WSDL files are normative. The specification already provides pointers to the Schema and WSDL files. For convenience, the specification, WSDL and Schema shall be packaged in a ZIP file, and made available as a downloadable file. Proposal 2 was accepted during March 14, 2006 F2F meeting. WS-Coordination specification: PDF Line numbers: 104-133. WS-BA specification: PDF Line numbers: 94-126. WS-AT specification: PDF Line numbers: 35-76. The reference links contained in the References section should use visible URLs, in order to enhance readability for those with accessibility problems. ws-coord ws-at ws-ba spec editorial Ram Jeyaraman Ram Jeyaraman Use visible URLs in References section. The proposed resolution was accepted during March 14, 2006 F2F meeting. WS-Coordination specification: PDF Line numbers: table row after line 84 with ns prefix wsa, 113-114, 147. WS-BA specification: PDF Line numbers: 107-108. WS-AT specification: PDF Line numbers: 51-53. To assist in discussions concerning the usage of WS-Addressing in the OASIS WS-TX specifications, it should be resolved whether the current 2004/08 WS-Addressing (http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/) or the W3C WS-Addressing specification (http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/) is the target WS-Addressing specification. ws-coord ws-at ws-ba spec design Joseph Fialli Joseph Fialli In the interest of looking forward, it would be best to update to the newest revision of the WS-Addressing specification. Update the WS-Coordination, WS-AT, and WS-BA specifications to reference the current PR submission draft of the WS-Addressing specification (http://www.w3.org/2005/08/addressing). The resolution to issue 30 should describe the effect this change has on the replyTo semantics. The resolution was accepted on April 06, 2006 TC call. WS-AT specification: PDF Line numbers: 475-477, 481-482. Under Section 9 "Use of WS-Addressing Headers", non-terminal notification messages MUST have a wsa:ReplyTo but is silent on wsa:MessageID. 2004 WS-Addressing specification requires wsa:MessageID when wsa:ReplyTo exists. ws-at spec design Joseph Fialli Joseph Fialli Add bullet "MUST include a wsa:ReplyTo header" to Non-terminal notification messages. (line 481-482). Instead of updating individual issues, a larger issue is to check and update all usages of WS-Addressing in the WS-TX specifications to be consistent with the latest WS-Addressing specification. This issue was closed with no action during March 14, 2006 F2F meeting. WS-AT specification: PDF Line numbers: Line 472 and 480. Currently we use wsa:ReplyTo for one-way messages in a way which although legal in terms of the latest CR draft of WS-Addressing, has led to confusion on a number of occasions. As an example, one use of wsa:ReplyTo is on Prepare->Prepared, where Prepare has a wsa:ReplyTo but the Prepared message is a separate (not response) message, because it could be sent autonomously and not actually in response to Prepare. The issue is that as far as WS-Addressing is concerned, wsa:ReplyTo should really only be used in the case of the request-response MEP, which is clearly not the case here. ws-at spec design Mark Little Mark Little The rules for where and when wsa:ReplyTo should be included and used within WS-AT are well defined, and particularly in respect to the interoperability scenarios. I propose that we replace wsa:ReplyTo with something specific to WS-TX (perhaps wsc:ReplyTo, wsc:OnewayTo, or somesuch). Addendum: Max suggested at the Raleigh f2f another potential resolution: that we use wsa:From. See proposal. Proposal 2 was accepted during May 04, 2006 TC call . WS-BA specification: Section 3.2, lines 244-258. BusinessAgreementWithCoordinatorCompletion is not tested for in the interoperability scenarios. This either needs to be fixed, with some scenarios added, or we should remove the protocol. I haven't seen any good arguments for why we should have this protocol within the BusinessActivity specification. If there is a requirement, then it seems more appropriate for a separate model (i.e., specification) to host this. ws-ba spec design Mark Little Mark Little Remove BusinessAgreementWithCoordinatorCompletion. Closed with no action. New interop scenarios to cover CoordinatorCompletion protocol has been added to the BA interop scenarios document. This resolution was accepted during the August 29-31, 2006 F2F meeting. WS-BA specification: Section 3, lines 151-168. The MixedOutcome is not tested for in the interoperability scenarios (AtomicOutcome is). This either needs to be fixed, with some scenarios added, or we should remove the capability. I haven't seen any good arguments for why we should have this protocol within the BusinessActivity specification. If there is a requirement, then it seems more appropriate for a separate model (i.e., specification) to host this. ws-ba spec design Mark Little Mark Little Remove MixedOutcome. Closed with no action. New interop scenarios to cover MixedOutcome coordination type has been added to the BA interop scenarios document. This resolution was accepted during the August 29-31, 2006 F2F meeting. WS-Coordination specification: PDF line numbers 238-240. Make precise statement on meaning (at WS-C level) of /CreateCoordinationContext/CurrentContext. The presence of this element has no meaning other than: a relationship of some kind is being created between an existing context and a new context. Details: In the course of discussions leading to resolution of issues 018 - 021, it seemed that differing interpretations and assumptions were likely when considering the meaning of the presence of the CurrentCoordinationContext element in the CreateCoordinationContext message. For example: under some circumstances (sub-coordination for an atomic outcome protocol) one might consider that the new and existing contexts were representations of the same overall activity (the atomic transaction tree). In that case, and in others, the presence of the relationship might subsequently be expressed in the sending of Register to the RS of the existing (current) context. However, in principle, the statement of relationship might be expressed in ways that do not involve use of Register. ws-coord spec editorial Alastair Green Alastair Green The document drafted by Max Feingold as a result of discussions on the 018-021 AI, seems like the right kind of wording, in the light of the above. The proposed resolution was accepted during May 04, 2006 TC call. i018 i019 i020 i021 WS-AT specification: New section required. Make precise statement on meaning (for WS-AT) of /CreateCoordinationContext/CurrentContext. WS-AT should state purpose and meaning of /CreateCoordinationContext/CurrentContext. The WS-C statement is very general. ws-at spec editorial Alastair Green Alastair Green The document (2006-03-21.Guaranteeing.Atomicity.of.Transaction.Tree.doc) contains a new section that a) defines the behaviour I deduce is intended and b) avoids stating whether a lazy or eager registration approach is taken (treating that as an implementation issue). Closed with no change during May 04, 2006 TC call. i018 i019 i020 i021 The term "Coordinator" or "coordinator" is used with three distinct meanings: A) as a synonym for "coordination service"; B) to describe the logical entity that coordinates all of the participants registered for a transaction; C) to describe the logical entity that executes a coordination protocol with respect to a single participant. These have different lifecycles and undergo distinct (though sometimes related) state transitions. Distinct terms should be used for each meaning and used consistently across the set of the specifications, to avoid ambiguity and confusion. Details: Meaning A: WS-Coordination explicitly offers "coordinator" as a synonym for "coordination service" (lines 16, 181, 627), and uses the term in that sense in other places (e.g. figure 1, lines 31, 318). This sense is used in WS-BA line 159 and 160 (strictly that is "implementation of a coordination service"). An A-Coordinator is a service with an indefinite lifetime, greater than a single coordinated activity and with no defined states. Meaning B: In WS-C the term Coordinator is also used to mean: the entity whose registration EPR and identifier is tranmitted in a CoordinationContext, and which is capable of receiving registrations of multiple participants. ("B-Coordinator"). WS-Coordination sometimes uses the term "coordination context" to refer to this entity (line 514), though usually "coordination context" means the transmissable datatype, as in lines 140-175. In WS-AT, "coordinator" is normally used in this sense (e.g. lines 95, 116, all of section 4.3.3). (In some cases, "coordination service" would be a meaningful alternative, in others not - which indicate it is not a synonym as in sense A). In WS-BA, "coordinator" is clearly of this sense in lines 157 and 158. A B-coordinator is state entity created with the CreateCoordinationContext and ending when all activity is over and it is forgotten (exact details of its termination depend on the coordination type) Meaning C: The term Coordinator is also used in WS-BA to mean: the sub-entity of a B-Coordinator that handles the execution of a protocol with respect to a single participant ("C-Coordinator"). The WS-AT does not use "coordinator" in quite this sense - the state tables appear to (but see separate issue) but lines 494-496 distinguish coordinator (sense B) and the state machines. In WS-BA, lines 221-234 use coordinator in sense C (since they refer to the state of a coordinator without regard to other participants) as do the state tables. A C-Coordinator is a state entity created when a Register message is received (if received when B-Coordinator is in appropriate state), and ending when the relationship with the participant is terminated (details depend on coordination type and protocol) It might be possible to push the interpretation of coordinator = "coordination service" in many cases, but it would seem unnatural. Understanding "coordinator" to mean sometimes "the continuing coordination service, used by numerous transactions", sometimes "a coordination service's view of a particular transaction" and sometimes "a coordination service's view of the state of a registered relationship with a particular participant service" is not helpful. A state entity should have a name, not be the anonymous view of a state from the perspective of a general entity. ws-coord ws-at ws-ba spec editorial Peter Furniss Peter Furniss A. WS-C: remove all references to "coordinator" that mean A-Coordinator, and replace them with "coordination service". B. WS-C/AT/BA: use the term "Coordinator" for B-Coordinator exclusively. C. WS-AT/BA: use the term "Bilateral Coordinator" for C-Coordinator, e.g. "Bilateral Coordinator View" in describing the coordinator view in a state table title. Closed with no change during August 10, 2006 TC call. WS-AT specification: section 10, lines 493 - 510. The WS-AT coordinator state tables do not provide explanation of what the states or internal events are, and do not provide specification of the interactions between the completion, volatile and durable protocols. Details: The WS-AT state tables are described as showing " the view of a coordinator or participant with respect to a single partner. A coordinator with multiple participants can be understood as a collection of independent coordinator state machines". In fact they appear to use the states and internal events of the multi-lateral coordinator but inbound events for a single partner. In the absence of any explanation, especially of the internal events, this is confusing (and there seem to be some inconsistencies). There is also little or no specification in the state tables of the interactions between the completion, volatile and durable protocols (which essentially determine that the transaction is atomic). Evidence of multilateralism: A bilateral state engine will move from None to Active on receiving Register. "Active" thus has to be interpreted as the state of the multilateral coordinator. Receipt of ReadOnly would cause a bilateral state engine to go from Active to None - the tables show it as having no effect on the state. Lack of protocol interaction: the tables provide no specification of the volatile-first behaviour - except perhaps in the Register/Preparing cell, which is cannot be harmonised with the rest of the table (see separate issue). If "User Commit" is to be interpreted as Commit on the Completion protocol (or its non-standardised equivalent), then a Prepare shouldn't be sent to a Durable Participant until all the Volatiles have replied. The Commit Decision event is presumably meant to occur when all participants have replied Prepared or ReadOnly, but according to the state table it could occur any time after Prepare has been sent. ws-at spec design Peter Furniss Peter Furniss Create separate tables for the multilateral and bilateral relationships, and define what all the states and events mean. See email . Proposal 2 was accepted during June 29th, 2006 TC call . i035 i037 WS-AT specification: section 10, lines 503/504: table row Register, column Preparing. The cell Register/Preparing cannot be interpreted in a way that is consistent with both the rest of the state table and with section 4.3.1 (lines 178-180). Details: The states of the WS-AT have to be interpreted as the state of the multi-lateral coordinator - events occur that change the state of a bilateral relationship, but do not not change the state in the table (see issue Coordinator state machine unclear and incomplete). Of the three cells that have different behaviour for volatile and durable protocols, the two in the None state have to be understood to mean that a message from a durable participant causes the Durable: behaviour, from a volatile participant the Volatile: (since there is no modelled knowledge of the participant, this has to be the case). However, according to section 4.3.1 (and common practice in other protocols), new registrations are permitted while volatile participants are being prepared. The only way to interpret the Register/Preparing cell to align with that would be to declare that the "Preparing" state is that of a bilateral relationship, and the Volatile/Durable refers to the type of that relationship, and not that in the Register. This contradicts both the meaning of Volatile: Durable: in the other cells, and the multi-lateral interpretation of the states. ws-at spec design Peter Furniss Peter Furniss This will be resolved if separate tables for the multilateral and bilateral relationships are created as proposed for the issue WS-AT: Coordinator state machine unclear and incomplete issue. See email. Summary: 1. Remove the 2 Register/RegisterResponse rows from the 2PC state tables. 2. Augment the text in section 4.3.1 so that we do not lose any information as a result of removing these rows. Agreed text: "Further participants may register with the coordinator until the coordinator issues a Prepare to any durable participant. Once this has happened the Registration Service for the coordinator MUST respond to any further Register request with a Cannot Register Participant fault message". Note to editors: Please ensure that the space delimited form of the fault 'Cannot Register Participant' is used, instead of 'CannotRegisterParticipant', across all occurences. Proposal 2 was accepted during June 15, 2006 TC meeting. i036 WS-AT specification: ws-at section 10, lines 503/505; participant table: Expires times out/Active, /Preparing; ws-at: seciton 6.1, line 371. The cells for Expires Times out for Active and Prepared states should include the (internal) Initiate Rollback and Forget actions. Details: Expires Times out should trigger the same internal events as receipt of rollback - otherwise the state machine will never exit. (An argument could be raised that the "initiate rollback" action is superfluous, since the corresponding actions on the bound data [the application-dependent state that will be changed by the transaction if it commits] for preparing and committing are not mentioned. But the point of this issue that Expires Times out and received rollback should trigger the same internal actions, however those are specified). ws-at spec design Peter Furniss Peter Furniss Make the Expires Times out cells for Active and Preparing states the same as the Rollback cell. Proposal was accepted during July 13, 2006 TC call. WS-AT specification: section 10, lines 503/505 tables rows Prepared, Relay, column None. The requirement that a coordinator with no current knowledge of a participant can determine which protocol it previously registered with from an incoming Prepared or Replay messages imposes unnecessary requirements on implementations. The desired functionality can be achieved with a common response to all such messages from "orphans", and letting the participant interpret that response. Since a returned fault does not show in the state tables, there is currently no behaviour specified for the volatile participant that sent the Replay or Prepared (this will become a separate issue if the main one is rejected, but it gets subsumed if this is fixed). Details: Background: The None state for WS-AT means that there is no record of the transaction - either because the transaction completed (rolledback or committed) or the coordinator crashed (and thus implicitly rolledback). Among correct implementations, Prepared and Replay messages received in the None state can only come from participants that were registered prior to the completion or crash, but did not receive a Commit or Rollback message. For a durable participant, this cannot happen if the transaction committed - the coordinator cannot forget the transaction until it has received Committed from the durable participant. Thus if the Prepared or Replay are received from a durable participant in the None state, it can be inferred with certainty that the transaction rolledback (by intent or crash). For volatile participants however, it is legitimate for the coordinator to delete its commit log record after receiving Committed from all durable participants, without waiting for any response from volatile participants. If there is a crash at this point (or just some lost messages), Prepared or Replay can be received from a volatile participant and find the coordinator in state "None". The issue: The specification currently requires that the coordinator distinguish between the two kinds of registration. This in turn requires that there is something about the Prepared or Replay message that allows the coordinator to determine the protocol of the forgotten registration (ipso facto, it has no specific, local information). Since there is nothing in the Prepared or Replay messages as such, this can only be something carried in or implied from the addressing for the coordinator. Although this can of course be done, and for some implementations may be entirely natural (e.g. if they have twinned-but-distinct multi-lateral coordinators for volatile and durable), for others it will be unnatural. There seems no reason for imposing this peculiarity (other perhaps than the unstated aesthetic that the coordinator has the driving seat in this protocol). If the coordinator gave the same response to Prepared/Replay from either protocol, it would be up to the participant to determine how it should treat this response. Since the participant certainly knows how it registered, there would be no ambiguity. (This issue has been distinguished from the question of using Invalid State in the volatile case - it would be even worse to use for InvalidState for the both protocols). There is currently no defined behaviour for the volatile participant that sends Replay or Prepared (since fault behaviour is not defined). ws-at spec design Peter Furniss Peter Furniss Define new message UnknownTransactionOutcome. Amend state table for Coordinator to send the new message when Prepared or Replay are received in state None. Amend state table for Participant with row for inbound "UnknownTransactionOutcome" this is invalid (shouldn't happen) in all states except PreparedSuccess. in PreparedSuccess if participant is Durable action is Initiate Rollback and Forget, transition to Aborting. if participant is Volatile, action is Forget, transition to new state UnknownOutcome. UnknownOutcome state has transition to None on All Forgotten event. All other Inbound Events are ignored, without transition. Define new fault UnknownTransaction. Amend state table for Coordinator to send the new fault to volatile participants, when Prepared or Replay are received in state None. Proposal 2 was accepted during May 31 - June 01, 2006 (Dublin) F2F meeting. i043 WS-AT specification: section 10, lines 503/505 tables rows Prepared, Relay, column None. The requirement that a coordinator with no current knowledge of a participant can determine which protocol it previously registered with from an incoming Prepared or Replay messages imposes unnecessary requirements on implementations. The desired functionality can be achieved with a common response to all such messages from "orphans", and letting the participant interpret that response. Since a returned fault does not show in the state tables, there is currently no behaviour specified for the volatile participant that sent the Replay or Prepared (this will become a separate issue if the main one is rejected, but it gets subsumed if this is fixed). Details: Background: The None state for WS-AT means that there is no record of the transaction - either because the transaction completed (rolledback or committed) or the coordinator crashed (and thus implicitly rolledback). Among correct implementations, Prepared and Replay messages received in the None state can only come from participants that were registered prior to the completion or crash, but did not receive a Commit or Rollback message. For a durable participant, this cannot happen if the transaction committed - the coordinator cannot forget the transaction until it has received Committed from the durable participant. Thus if the Prepared or Replay are received from a durable participant in the None state, it can be inferred with certainty that the transaction rolledback (by intent or crash). For volatile participants however, it is legitimate for the coordinator to delete its commit log record after receiving Committed from all durable participants, without waiting for any response from volatile participants. If there is a crash at this point (or just some lost messages), Prepared or Replay can be received from a volatile participant and find the coordinator in state "None". The issue: The specification currently requires that the coordinator distinguish between the two kinds of registration. This in turn requires that there is something about the Prepared or Replay message that allows the coordinator to determine the protocol of the forgotten registration (ipso facto, it has no specific, local information). Since there is nothing in the Prepared or Replay messages as such, this can only be something carried in or implied from the addressing for the coordinator. Although this can of course be done, and for some implementations may be entirely natural (e.g. if they have twinned-but-distinct multi-lateral coordinators for volatile and durable), for others it will be unnatural. There seems no reason for imposing this peculiarity (other perhaps than the unstated aesthetic that the coordinator has the driving seat in this protocol). If the coordinator gave the same response to Prepared/Replay from either protocol, it would be up to the participant to determine how it should treat this response. Since the participant certainly knows how it registered, there would be no ambiguity. (This issue has been distinguished from the question of using Invalid State in the volatile case - it would be even worse to use for InvalidState for the both protocols). There is currently no defined behaviour for the volatile participant that sends Replay or Prepared (since fault behaviour is not defined). ws-at spec design Peter Furniss Peter Furniss Define new message UnknownTransactionOutcome. Amend state table for Coordinator to send the new message when Prepared or Replay are received in state None. Amend state table for Participant with row for inbound "UnknownTransactionOutcome" this is invalid (shouldn't happen) in all states except PreparedSuccess. in PreparedSuccess if participant is Durable action is Initiate Rollback and Forget, transition to Aborting. if participant is Volatile, action is Forget, transition to new state UnknownOutcome. UnknownOutcome state has transition to None on All Forgotten event. All other Inbound Events are ignored, without transition. Duplicate of issue i039. This issue was dropped during April 06, 2006 TC call. i043 WS-AT specification: ws-at section 10, lines 503/505; coordinator table: Committed/Active, Committed/Preparing; pariticipant table: Commit/Active, Commit/Preparing; ws-at: seciton 6.1, line 371. The receipt of a message when the receiver is in a state such that the event cannot occur between correct implementations should not cause a state transition and allow the transaction to complete "successfully". There is no need to distinguish "InvalidState" and "InconsistentInternalState". Details: Background: InvalidState is defined in WS-Coordinator as being an unrecoverable condition, and in all the cases where it is a defined response in the WS-AT tables can only occur if one of the implementations is broken/bugged (apart than the volatile Prepared/None case, see separate issue). Providing a defined state transition, as if the circumstance were expected and could be recovered from is inappropriate. There can be no graceful completion of the protocol - it has gone fundamentally wrong. This does not preclude an implementation from attempting to tidy up and protecting its own resources, but there should be no required state transition for the implementation. The protocol exchange has gone off the map. The use of InconsistentInternalState to distinguish two cases where an invalid event occurs is unnecessary (and the definition in line 371 does not align with the use in the table - it is probably the coordinator that has been sending wrong messages). The use of InvalidState is appropriate in all cases. ws-at spec design Peter Furniss Peter Furniss The clearest solution would be to make invalid cells in the state tables empty, for the cells currently shown as InvalidState or InconsistentInternalState, and also for the N/A cells and explain this with text: "Where a cell is shown as empty - if the row is for an Inbound Event, an WS-C Invalid State fault should be returned. The subsequent behaviour of the implementation is undefined. - if the row is for an Internal Event, event cannot occur in this state. A TM should view these occurences as serious internal consistency issues." Having invalid cells empty makes it significantly easier to read and check the state tables. It becomes much clearer that they are essentially "sparse" and the path through the table can be followed more easily. AT spec wd-08, Section 6.1, line 375-377: Modify the definition of InternalInconsistentState fault as, "Inconsistent Internal State This fault is sent by a participant or coordinator to indicate that a protocol violation has been detected after it is no longer possible to change the outcome of the transaction. This is indicative of a global consistency failure and is an unrecoverable condition." Section 6.1, line 380, Change "[Subcode] wsat:InconsistentInternalState" to "[Subcode] wsat:Inconsistent Internal State". Section 10, line 518, The following cells in the Coordinator View table need to be throw Inconsistent Internal State fault. 1. {ReadOnly; PreparedSuccess, Committing} 2. {Aborted; PreparedSuccess, Committing} 3. {Committed; PreparedSuccess, Aborting} Note to Editors: Please ensure all occurences of 'InconsistentInternalState' fault is replaced with the space delimited form 'Inconsistent Internal State'. proposal 2 was accepted during August 10, 2006 TC call. WS-BA specification: Appendix C, lines 491-524. The WS-BA state tables show states as rows, and received messages as columns. This is the opposite to the convention adopted by WS-AT. The two specification should have a consistent convention, to ease comparison. ws-ba spec editorial Peter Furniss Peter Furniss Change WS-BA state tables to use the same state/column, message/row convention as the WS-AT spec. The proposed resolution was accepted during May 04, 2006 TC call. WS-AT specification: section 10, lines 503/505 tables rows Prepared, Relay, column None. The use of Invalid State as the response to a Prepared or Replay received from a participant that had a (forgotten) volatile registration is inconsistent with the definition of Invalid State in WS-Coordination and requires special processing by implementations to handle this non-fault fault. Issue Details Background - see separate issue : Coordinator should not distinguish protocol of orphaned participants. The defined meaning of InvalidState in WS-Coordination is "This fault is sent by either the coordinator or a participant to indicate that the endpoint that generates the fault has received a message that is not valid for its current state. This is an unrecoverable condition." Occurence of InvalidState according to this definition, and in all its other occurrences in the state tables for WS-AT or WS-BA imply that one or other of the implementations is bugged. It is to be expected that implementations would report such a fault conspicuously. This is an inappropriate message in this instance. The meaning the coordinator needs to send to the participant is something like: "Legitimate message received, but transaction outcome is unknown: I can't help you". Since the volatile participant, by definition, doesn't care very much, implementations will not want to contaminate their error logs with reporting these occurrences, which can occur between fully correct implementations. They will either have to insert special code to identify this circumstance or annoy their users. ws-at spec design Peter Furniss Peter Furniss Use a new message, as proposed for issue WS-AT: Coordinator should not distinguish protocol of orphaned participants. Use a new fault UnknownTransaction. Proposal 2 was accepted during May 31 - June 01, 2006 (Dublin) F2F meeting. The line 619 "Request messages MUST contain a [reply endpoint] property whose [address] property is not set to 'http://www.w3.org/2005/08/addressing/anonymous' or 'http://www.w3.org/2005/08/addressing/none'." has been removed. i039 WS-Coordination specification: ll. 317 - 321. Section 3.2, "Registration Service". Current text from resolution to 007 implies that /ParticipantProtocolService endpoint can be used to detect duplicate registrations. Issue Details ll. 317 - 321 read: "If a participant sends multiple Register requests for the same activity, the participant MUST be prepared to correctly handle duplicate protocol messages from the coordinator. One simple strategy for accomplishing this is for the participant to generate a unique reference parameter for each participant Endpoint Reference that it provides in a Register request. The manner in which the participant handles duplicate protocol messages depends on the specific coordination type and coordination protocol." The sentence beginning "One simple strategy ..." is ambiguous (at best) about which EPR is being referred to. The Register request supplies a /ParticipantProtocolService EPR, and a wsa:ReplyTo EPR. The strategy being discussed here can only work if the WS-A [reply endpoint] has a value that unambiguously identifies (for the registering service) the participant. The PPS EPR is irrelevant. Further, message ids could be used by the registering service to achieve the same level of knowledge of duplication. ws-coord spec design Alastair Green Alastair Green Option 1: Replace the sentence beginning "One simple strategy ..." with the following sentence: "One simple strategy for accomplishing this is for the sender of Register to ensure that the the WS-Addressing [reply endpoint] Endpoint Reference that it provides in a Register request identifies the participant unambiguously from the sender's standpoint." Option 2: Replace the sentence beginning "One simple strategy ..." with the following sentence: "This can be accomplished either by the sender of Register keeping track of the message ids of Register messages that refer to the same participant, or by the sender of Register ensuring that the the WS-Addressing [reply endpoint] Endpoint Reference that it provides in a Register request identifies the participant unambiguously from the sender's standpoint. Each of these techniques will allow duplicate RegisterResponses which refer to the same participant to be detected by the requester." Closed with no action during May 04, 2006 TC call. WS-AT specification: Section 5.2, lines 242-257. The use of "wsp:Optional" on /wsat:ATAssertion for conditionally flowing atomic transaction context in Section 5.2 in WS-AtomicTransaction (WS-AT) is fundamentally different from the use of "wsp:Optional" meaning "can be present or not". Issue Details The "can be present or not" interpretation used in the WS-Policy (http://schemas.xmlsoap.org/ws/2004/09/policy/) specification as implied by the description of normalization, where "optional" is described as "an attribute that is a syntactic shortcut for expressing policy alternatives with and without the assertion", and is found in Section 4.3, Compact Policy Expression (see specifically Section 4.3.1). The basic WS-Policy concept is that *one* set of alternatives is selected for a given interaction. So, using the WS-Policy [1] specified semantics, a client should either agree to always provide a transaction context or agree never to provide it. This implies a service contract where a transaction context is either always present or always absent. In contrast in WS-AT, the semantics are "if an atomic transaction context exist at the time the operation request is invoked, then flow it with the request". So the client has not agreed to provide a transaction context for all invocations of the operation request. This is equivalent to client and server agreeing to support multiple sets of alternatives in the same interaction. This deviates from standard WS-Policy semantics; for example, there is no way to say "in this interaction, we agree to use either AES encryption or 3DES encryption", with the server prepared to accept both from the same client in the same interaction, which is another variant of accepting multiple alternatives. What is the potential impact? A policy parser does not have a standard way to normalize a policy. The parser has to know whether "optional" means "if a concept is present, flow it with the request" or if it means "choose one alternative or the other". This supports our charter that the policy assertions be usable in the policy framework defined by WS-Policy rather than defining concepts that surround those functions. Charter located at http://www.oasis-open.org/committees/ws-tx/charter.php. ws-at spec design Monica J Martin Monica J Martin Refer to the original email for details on the proposal. Remove the sentence "Presence of both policy alternatives indicates that the behavior indicated by the assertion is optional, such that an atomic transaction MAY be flowed inside a requester's message. The absence of the assertion is interpreted to mean that a transaction SHOULD NOT be flowed inside a requester's message.". Further, the change suggested in this email. Proposal 2 was accepted during May 31 - June 01, 2006 (Dublin) F2F meeting. WS-AT specification: Whole spec, and specifically, Section 10, "State Tables", Coordinator View table, between ll. 503 and 504, Participant View table, between ll. 510 and 511. WS-AT spec only mentions logging in passing, or implicitly. ll. 393 - 394,(Section 7, "Security Model"): "The participant can only prove its identity to the coordinator when it indicates that the specified transaction is not in its log and assumed committed." In the state tables the undefined internal events "Write Done" and "Write Failed" might be taken to mean "persistent write done" and "persistent write failed" -- or then again they might be taken to mean "everything still fine" and "something went wrong". Recovery (usually taken to mean crash recovery, and therefore implying persistent records) is mentioned in this sense only once, as follows (ll. 221-223, Section 4.3.3. "2PC Diagram and Notifications"): "Replay -- Upon receipt of this notification, the coordinator may assume the participant has suffered a recoverable failure. It should resend the last appropriate protocol notification." The design intent may have been either of the following: A. Do not mandate any persistence or recovery strategy -- the protocol should be capable of being run in a volatile, no log manner, as well as using conventional logging techniques. (Dropping the D of ACID). B. We all know that we mean to log, so let's not bother to mention it. I believe A. is the correct design intent expressed by the input document authors at the inaugural TC meeting in November, and editorial changes should be made that clarify that intent. ws-at spec design Alastair Green Alastair Green a) Amend ll. 94 - 95 to delete the words "not persistent and" from the following sentence: "The actions taken prior to commit are only tentative (i.e., not persistent and not visible to other activities)." b) Insert after l. 104 a new paragraph as follows: "While most atomic transaction systems use persistent logs to ensure consistent execution of transaction completion in the face of process/processor failure, WS-AtomicTransaction does not mandate any persistence policy or strategy. Its protocols are capable of being executed by endpoints which do log, and by those that do not. Quality of service with respect to crash recovery is left as an implementation, deployment and run-time issue." c) Change name of state table actions "Write Done" and "Write Failed" to "Decision Recorded" and "Decision Unrecorded". The issue was closed with no action during July 27, 2006 TC call . i048 WS-AT specification: l. 146, Section 4.2, "Completion Protocol", and l. 171, Section 4.3, "Two-Phase Commit Protocol". WS-AT spec could be taken to imply that Completion protocol required to engender User Commit internal event. Use of Completion protocol should not be mandated. ll. 176-177 read: "Upon receiving a Commit notification in the completion protocol, the root coordinator begins the prepare phase of all participants registered for the Volatile 2PC protocol." This is an example of how the state table internal event User Commit can be engendered. An implementation could use an API method (rather than an interoperable message) to engender User Commit (truly make it an "internal event"). ws-at spec design Alastair Green Alastair Green a) Add a sentence after the existing sentence ending "... it should attempt to commit the transaction" (l. 159) that reads: "Receipt of this notification generates the 2PC Coordinator View state table internal event User Commit." b) Add a sentence after the existing sentence ending "... it should abort the transaction" (l. 162) that reads: "Receipt of this notification generates the 2PC Coordinator View state table internal event User Rollback." c) Add a sentence after the existing sentence ending "... a decision to commit" (l.166) that reads: "The action Return Committed in the 2PC Coordinator View state table engenders the transmission of this notification." d) Add a sentence after the existing sentence ending "... a decision to abort" (l.169) that reads: "The action Return Aborted in the 2PC Coordinator View state table engenders the transmission of this notification." e) Replace the sentence at the very end of Section 4.2 "Completion Protocol", l. 170, which currently reads: "Conforming implementations must implement Completion.", with the following: "Conforming implementations MUST implement the Coordinator role in the Completion protocol (i.e. be prepared to receive Commit and Rollback, and to send Committed and Aborted), but need not implement the matching Initiator role. Applications/implementations may use this protocol to signal application termination requests to a coordinator, or they may use an implementation-defined mechanism to stimulate the 2PC Coordinator View internal events User Commit and User Rollback." f) Amend the first sentence of Section 4.3 (l. 171) to read: "Upon the internal event User Commit (which may result from receiving a Commit notification in the completion protocol) a root coordinator begins the prepare phase of all participants registered for the Volatile 2PC protocol." WS-AT specification wd-08, Replace line 179 with "A coordination service that supports an Activation service MUST support the Completion protocol.". proposal 2 was accepted during August 10, 2006 TC call. i050 WS-AT specification: Section 10, "State Tables", Coordinator View table, between ll. 503 and 504, Participant View table, between ll. 510 and 511. None of the user events are defined. Many of the less obvious state table actions are undefined. This issue attempts to carve out and resolve a specific sub-issue raised in less detail in issue 036. While reviewing the AT tables I wrote myself a rough glossary of events and actions, to make sure I understood the tables correctly. I think other readers would benefit from the same kind of guidance, so I've polished it up as a proposed addition to the spec. The internal events and actions should be defined to avoid misunderstanding, ambiguity and underspecification, and to achive this, it is much easier to define them separately for Coordinator View and Participant View. For example, "User commit" means "the application has decided to request the transaction be committed". "Commit decision" means: "The coordinator has determined that the votes of remaining participants are all in, and that commit-phase processing can commence; a log of this decision will now be made." To take another example: "Record vote" really means "no-op", whereas "Record Commit" (usually) means "attempt to write a log record". Or, again: "Record Outcome" means record coordinator wide commit decision in CV, but "Record Commit" means "record prepared decision" in PV. Or, further: "User Commit" is an internal event that could be stimulated by Completion protocol Commit message being received, and the same, mutatis mutandis, for "User Rollback". An allied issue is the use of the term "Return" in state table actions meaning: send a "message", signal to the application that requested commit or rollback. This is not defined. All of these things are deducible, but it would be clearer and more precise to spell them out. There may be a case for renaming some of these events for greater clarity, but I have concentrated on writing down the meaning as I understand it. ws-at spec editorial Alastair Green Alastair Green Refer to the original email for details on the proposal. The issue was closed with no action during July 27, 2006 TC call . i036 i046 i054 WS-AT specification: Section 3, "Atomic Transaction Context", ll. 120-123, as amended by resolution of issue 023. Resolution of issue 023 blurs meaning of expiry for the coordinator and participant. Point of no return misdefined (does not accord with the state table). Fact that this attribute has no real meaning for completion protocol is not stated. Issue Details: The new text agreed in resolution of 023 at the March 2006 F2F reads: "A coordination context may have an Expires attribute. This attribute specifies the period, measured from the point in time at which the context was first received, after which a transaction may be terminated solely due to its length of operation. From that point forward, the transaction manager may elect to unilaterally roll back the transaction, so long as it has not transmitted a Commit or Prepared notification." But: 1) the transaction manager (better, the coordinator of the transaction) does not receive the context, it generates it. In other words, the transaction manager will start counting down to abortion of the transaction at some point no later than the time it first emits a context. 2) The entity that does receive the context is any registering service that chooses to hook a 2PC participant into the transaction. Such a recipient must never set a local expiry deadline for its registered participants which is earlier than the absolute time of receipt of the application message containing the context, plus the expiry. (Unless it has some way of deducing network latency.) The existence of such an actor is not made clear. 3) The definition of the "point of no return" is wrong (both for the coordinator and the participant). The point of no return, as per the state tables, is not the point of emission of the message, but the point of deciding to attempt a log write. 4) The expiry interval is effectively meaningless for the Completion protocol. Having been set (in the first place) by the initiator of the transaction, it can reasonably be assumed that the terminator will be directly aware of the interval concerned. In any event, what does it mean for a completion participant to "time out"? Its only effect could be to redeliver a rollback, which would be both duplicative and complex to specify. The expiry must be defined twice: in its effect on the coordinator, and in its effect on registered participants. The definition of its meaning should be restricted to 2PC participants. The definition of the point of no return should be changed. Strictly speaking it could be omitted altogether: the internal event of decision to go prepared or to commit creates a state transition which precludes a subsquent rollback decision being attempted). However, that seems excessively opaque. Preferable to cross-refer the states. ws-at spec design Alastair Green Alastair Green Change the quoted section to read: "A coordination context may have an Expires attribute. This attribute specifies the period, measured from the point in time at which the context was first published in a CreateCoordinationContextResponse message, before whose passage a transaction will not be terminated by the coordinator solely due to its length of operation. After that period has elapsed, the coordinator may elect to unilaterally roll back the transaction, so long as it has not yet made a decision to record commit (i.e. entered the state PreparedSuccess). This attribute can be used by any recipient of a coordination context which registers a 2PC participant to calculate the point in time at which the participant can safely decide to rollback because of delay in receiving a Prepare message. A 2PC participant which has not yet decided to record prepare (i.e. entered the state Prepared) may rollback after the Expires interval has elapsed since the point at which the registrar of that participant received the coordination context message." If you want to avoid duplication of the state table, this could be abbreviated to: "A coordination context may have an Expires attribute. This attribute specifies the period, measured from the point in time at which the context was first published in a CreateCoordinationContextResponse message, before whose passage a transaction will not be terminated by the coordinator solely due to its length of operation. After that period has elapsed, the coordinator may elect to unilaterally attempt to roll back the transaction. This attribute can be used by any recipient of a coordination context which registers a 2PC participant to calculate the point in time at which the participant can safely decide to rollback because of delay in receiving a Prepare message. A 2PC participant may attempt to rollback after the Expires interval has elapsed since the point at which the registrar of that participant received the coordination context message." See email . Proposal 2 was accepted during July 13, 2006 TC call. Editors to check if the "may"s in the proposed text should be upper case or lower case. i023 WS-AT specification: Section 4.2, "Completion Protocol", l. 146. Only root coordinators can accept registrations for Completion protocol. Others must fault. ws-at spec design Alastair Green Alastair Green Add new para at l. 151 as follows: "An initiator MUST NOT target a registration for the Completion Protocol at a Subordinate Coordinator. The Registration Service for a Subordinate Coordinator must respond to an attempt to register for this coordination protocol with the WS-Coordination fault CannotRegisterParticipant." WS-AT wd-08 version, insert before line 161: "A Completion protocol coordinator must be the root coordinator of an atomic transaction. The registration service for a subordinate coordinator MUST respond to an attempt to register for this coordination protocol with the WS-Coordination fault Cannot Register Participant." proposal 2 was accepted during August 10, 2006 TC call. WS-AT specification: Section 10, "State Tables", Coordinator View table, between ll. 503 and 504. Late registration of 2PC participants not correctly stated in CV state table. Issue Details: WS-AT Coordinator View state table, row (Inbound Event) Register, column (State) Preparing, reads as follows: Durable: Invalid State --> Aborting Volatile: Send RegisterResponse --> Active The transaction moves into the Preparing state as a result of a User Commit internal event, aka an application instruction to the coordinator to initiate 2PC processsing. For 2PC to work correctly it is necessary to freeze the pool of voters before the polls close. In theory this need not happen till the very last vote of the current pool has been received (the list can be extended while being processed). However, WS-AT in common with other atomic TMs and protocols (and with other types of election) chooses to simplify by freezing the pool when the polls open, i.e. when the application chooses to request commitment, at the beginning of the prepare (voting) phase. The argument behind this is that the terminating (demarcating) application must have figured out (by some application protocol) that all the expected participating services are involved (usually termed checking), otherwise it wouldn't have requested commitment. With an atomic-only commitment protocol like AT this is reasonable. We should therefore never see an unexpected late registration of a durable participant, because the application should not have requested commit if all services are not yet involved. This is the current situation for late durable registrations. However, by this logic we should also expect that a volatile 2PC participant should never be registered late (unknown to the terminating application), once prepare phase processing has commenced. The vote of a volatile participant is good enough to veto the transaction: why should the number of volatile participants be considered any less relevant than the number of durable participants? There seems no reason to differentiate the reaction of the coordinator to late registration of Volatile and Durable participants. ws-at spec design Alastair Green Alastair Green Amend WS-AT Coordinator View state table, row (Inbound Event) Register, column (State) Preparing, to read as follows: Invalid State --> Aborting This issue has been dropped; the submitter has withdrawn the issue. Refer to the minutes of April 20, 2006 TC conference call. i037 WS-AT specification: Coordinator View State Table, after l. 503. Replay reactions defined in current CV state table will cause unnecessary transaction aborts. Issue Details: The cells in row (Inbound Messages) Replay, columns (States) Active and Preparing read: Active: Send Rollback --> Aborting Preparing: Send Rollback --> Aborting Replay message means: "play it again Sam", not "demolish the piano". Case A. If the last thing they sent was Prepared, and it got through (we're Preparing and we've recorded their vote), and they've recovered, and they're waiting for a Commit or a Rollback, then we need to Ignore the Replay (just like if they send it when we've done our own housekeeping, and moved to Prepared Success). Case B. If the message didn't get through, and we've processed User Commit then we could be in the Preparing state, but have no record of their vote. In that case we'd have to replay Prepare to indicate to them, send us your vote again. Case C. If the last thing we received was Register, and we haven't processed User Commit, then we're still Active and they won't have logged. Replay won't happen on crash recovery (no log record to recover off), but it could be used to say to the coordinator "Are you still there? Should I crap out?" (i.e., because of impatience). We can't stop them using Replay in that fashion. Our only sensible response would have to be: silence (we don't have a blank ack to a ping), i.e. to Ignore. There is no harm in them doing this, even though it is pointless. You could argue that this should be a N/A but that seems heavy-handed. ws-at spec design Alastair Green Alastair Green As the state tables do not differentiate between Preparing/no vote recorded and Preparing/vote recorded, it seems easiest to always resend Prepare in the Preparing state. Therefore: Replace the current text in the cells in row (Inbound Messages) Replay, columns (States) Active and Preparing with: Active: Ignore --> Active Preparing: Resend Prepare --> Preparing Remove Replay message. Proposal 2 was accepted during May 31 - June 01, 2006 (Dublin) F2F meeting. i046 i053 WS-AT specification: Section 3.4, "Two-Phase Commit Protocol", ll. 221-223 Coordinator View State Table, after l. 503. Replay is a pointless message. Replay the last message sent, if any. Issue Details: Replay is a universal synonym for "resend the last message sent, if any". Better and simpler to remove it, and rest on the rule that a coordinator and a participant can both, if feeling lonely, resend the last message sent, if any. (This rule is stated in the proposed resolution to related issue: "WS-AT: Comms Times Out internal event should be removed from state tables", and is needed in any event.) ws-at spec design Alastair Green Alastair Green a) Remove lines 221-223. b) Remove the row labelled (Inbound Messages) Replay in the Coordinator View state table. The proposed resolution was accepted during May 31 - June 01, 2006 (Dublin) F2F meeting. i052 i054 WS-AT specification: Coordinator View State Table, after l. 503 Participant View State Table, after l. 510. Comms Times Out internal event and its concomitant action (do it again) is universally applicable to all send/resend situations. These are not (cannot feasibly) be called out as separate states. This vitiates the purpose of the event in the tables. ws-at spec design Alastair Green Alastair Green a) Remove the rows labelled "Comms Times Out" in both CV and PV state tables. b) Add a note (either in Section 9 or in Section 10) saying: "Note that any attempt to send a notification message may result in a communications failure. It is always legitimate to attempt a retry in such circumstances. It is also legitimate to retry a send if an expected response has not been received in a timely fashion. The definition of "timely" and the retry strategy used are implementation concerns. However, complete failure to retry in all circumstances will almost certainly lead to hung transactions." The issue was closed with no action during July 27, 2006 TC call . i048 WS-AT specification: Section 10, "State Tables", Coordinator View table, between ll. 503 and 504. If transaction in state None, and event User Commit or User Rollback arises, then action is to Return Aborted (aka tell application that the transaction was aborted). In fact transaction may just have been forgotten, and may either have been aborted or committed. Return value possibly contradicts reality, therefore. Issue Details: All Forgotten event arises when all participants have done action Forget. If this happens when transaction as a whole is in Aborting or Committting state then the state flips to None. User Commit or User Rollback event may then arise. (Replay of Completion protocol Commit, API replay). Response of coordinator state machine is to process action "Return Aborted". See WS-AT Coordinator View state table, rows (Internal Events) User Commit and User Rollback, which read as follows: User Commit/None: Return Aborted --> None User Rollback/None: Return Aborted --> None Clearly this information may be false. It is possible that we got to None via Committing, or via Aborting. The result was either Committed or Aborted. Naturally, if we have gone "All Forgotten" we have literally ... forgotten which it was. ws-at spec design Alastair Green Alastair Green a) Amend state table cells referred to in problem description to read: User Commit/None: Return Unknown --> None User Rollback/None: Return Unknown --> None b) Define new fault for use by Completion protocol, called UnknownOutcome, which can be returned if this happens. See document . Proposal 2 was accepted during May 31 - June 01, 2006 (Dublin) F2F meeting. i056 WS-AT specification: Section 10, "State Tables", Coordinator View table, between ll. 503 and 504. Issue 010 proposed that replays of Completion protocol messages should be permitted, to allow initiators to discover state of transaction after initial termination request had been made. This was rejected almost unanimously. However, state tables permit replay. Issue Details: WS-AT Coordinator View state table, row (Internal Events) User Commit reads as follows: None: Return Aborted --> None Active: Send Prepare --> Preparing Preparing: Ignore --> Preparing Prepared: N/A Prepared Success: Ignore --> Prepared Success Committing: Return Committed --> Committing Aborting: Return Aborted --> Aborted Similar things happen with row User Rollback. Reception of User Commit engendered by Completion protocol Commit message may occur twice as a result of impatience, lost messages, transport bounce. State table handles this happily, replaying known outcomes (e.g if event arises when Aborting, Commit message will be responded to with Committed, even though message has already been sent on event Write Done. I like that, but the TC doesn't, by 16 to 1. Note that this issue is very tightly related to "WS-AT: User Commit and User Rollback should not return Aborted in None state". If all become forgotten (every participant goes aborted or committed) then the state flips to None. Speed at which that happens cannot be dictated (forgetting is a non-critical path activity, that may be deferred to some form of garbage collection or deferred for ever in a given implementation). Replays are therefore always possible in principle. ws-at spec design Alastair Green Alastair Green EITHER: Make text of completion protocol, definition of notification types etc conform with state table and recognize that duplicate Completion protocol Commits and Rollbacks cannot easily or sensibly be stopped (See Register/RegisterResponse discussion). OR: Ban duplicate responses in the state tables by faulting duplicate events. See email . Proposal 2 was accepted during July 13, 2006 TC call. i055 WS-AT specification: l. 191, Section 4.3, "Two-Phase Commit Protocol", diagram. Coordinator and Participant View State Tables, l. 503 onwards. The state tables show (in model and in detail) a substantially different view form the abstract protocol diagrams. Need to state that fact. Issue Details: The conceptual character of the protocol diagrams is not clear enough. The predominance or override of the state tables needs to be stated explicitly. The diagrams do not have the same states or state transitions as the state tables. They are good simplifications which situate readers at a first pass, but no more than that. Similarly the text that accompanies them. ws-at spec editorial Alastair Green Alastair Green Replace the sentence on l. 191 with the following: "The diagram and text in this section give a simplified, conceptual non-normative overview of the way in which the 2PC protocol works. The state tables in Section 10, "State Tables" are detailed and normative." [This resolution requires refinement if Replay is retained, as the only statement about what Replay means and when it might be sent is in this section.] The following text refers to CD 01 version of the AT specification. Line 152 and 191 currently state: "The diagram below illustrates the protocol abstractly.". Append the sentence "Refer to the section State Tables for a detailed description of this protocol." to the text at both lines. Editors: Please add a hyperlink to the phrase "State Tables" in the newly added text. Proposal 2 was accepted during July 27, 2006 TC call . Text within WS-C refers to Referencing Specification. We have no formal definition of that. ws-coord spec editorial Mark Little Mark Little One or more other specifications, such as (but not limited to) WS-AtomicTransaction may reference the WS-Coordination specification. Referencing Specifications are generally used to construct concrete protocols based on WS-Coordination. The usage of optional items in WS-Coordination, or those protocol aspects where terms such as MAY or SHOULD are used, may be further restricted by the requirements of a Referencing Specification. For the purpose of this document, the term Referencing Specification covers both formal specifications and more general applications that use WS-Coordination. Use the phrase "When used by a specification that references this specification, these faults are targeted ...", instead of "Referencing Specification". Proposal 2 was accepted during May 31 - June 01, 2006 (Dublin) F2F meeting. With the resolution of Issue 30, the specifications (coord, at, ba) have two kinds of indications: Faults (definined in ws coord) which map to ws-addressing fault model. "notifications" (from ws at, ba) which do not map to ws addressing faults, and which are treated as first class "requests" from ws addressing perspective. Mapping the second kind of indication to a soap fault, but not a ws addressing fault, will inevitably cause confustion for implementers of this spec. ws-coord ws-at ws-ba spec design Tom Rutt Tom Rutt Instead of mapping the "notifications" to soap fault syntax, define a new schema type {ProtocolEventIndication) which conveys the proper syntax for the contents of these protocol notifications. Have each individual protocolEventIndication be mapped to this new syntax, as a proper ws addressing request message. This issue was closed with no action during May 31 - June 01, 2006 (Dublin) F2F meeting. Section 6, ll.333 - 335. Text relating to resolution of Issue 030 does not make sense in this context. Issue Details: The phrase "...protocol fault handling rules defined for that protocol" does not makes sense when the protocol concerned is this one, WS-AT. ws-at spec editorial Alastair Green Alastair Green Amend text to say: '...protocol fault handling rules defined in Section 9 "Use of WS-Addressing Headers" of this specification.' Closed with no change during August 10, 2006 TC call. Section 10, "State Tables", Coordinator View table, between ll. 503 and 504, and Participant View table following. PV state table appears to prohibit rollback decision in Active state, tho' CV would accept message if sent. Same applies to ReadOnly. Issue Details: PV state table Row Rollback Decision, State Active, N/A -- means cannot occur. This implies that participant can never make decision to abort until it has received Prepare. But Expires Times Out generates spontaneous abort: it is safe against the CV table. Not clear why P cannot abort prior to receiving Prepare. Similarly: PV state table All Forgotten, State Active, N/A -- means cannot occur. This implies that participant cannot go read-only until it has received Prepare. CV state table Row Aborted, State Active, action: Forget; state Aborting. This cell cannot be entered if Prepare has already been sent (wd be in state Preparing). But PV can only send if expires times out. CV state table Read Only, State Active, action: Forget; state Active. This cell cannot be entered: if Prepare has already been sent C would be in state Preparing. PV cannot send Read Only in Active state. Therefore, CV in Active state is able to accept messages that PV can never send (Read Only) or that it can only send in a very restricted circumstance. From the standpoint of correctness and speed of transaction resolution, there is no argument against allowing Participants to spontaneously prepare (q.v. Gray/Lamport, "Paxos Commit"), vote rollback, or go read-only (i.e. to make these decisions prior to receiving Prepare). ws-at spec design Alastair Green Alastair Green Alter state tables to permit spontaneous preparation, abortion and resignation, as per attached Word document. If this is not accepted, the un-enterable cell (Read Only/Active) in CV needs to be set to N/A. See document. See email . Proposal 2 was accepted during August 24, 2006 TC call. Section 10, "State Tables", Coordinator View table, between ll. 503 and 504. Prepared column in CV state table is redundant. Issue Details: Prepared states are never entered (are all N/A) in CV state table. ws-at spec editorial Alastair Green Alastair Green Remove Prepared column from CV state table. Proposal was accepted during July 13, 2006 TC call. Section 3.4, "Two-Phase Commit Protocol", ll. 221-223 Coordinator View State Table, after l. 503 Participant View State Table, thereafter. Coordinator and Participant logging behaviour for Volatile participants is not defined. Issue Details: The following sentence comes from the original statement of Issue 039 (authored by Peter Furniss): 'For volatile participants however, it is legitimate for the coordinator to delete its commit log record after receiving Committed from all durable participants, without waiting for any response from volatile participants. If there is a crash at this point (or just some lost messages), Prepared or Replay can be received from a volatile participant and find the coordinator in state "None".' This is, I believe, an understanding derived from discussion with one of the input authors at the Raleigh interop event in January 2005. This is one implementation of the spec statement (l. 180): "A volatile recipient is not guaranteed to receive a notification of the transaction's outcome." That statement can also be fulfilled by a volatile participant not logging its prepared state. This will prevent it always receiving a known outcome (i.e. there will be no crash recovery of the Participant). The interoperable behaviour in these two cases is different. Behaviour in the case where the PV does not log, and the coordinator deletes its log after receiving all durable Committeds, is different again. The state tables do not capture the expected behaviour of either the coordinator, or the Participant, with respect to logging. ws-at spec editorial Alastair Green Alastair Green Discuss and clarify the design intent, and ensure that it is captured in the spec, preferably in the state tables. Section 7, line.619. Spec unnecessarily restricts anonymous ReplyTo in request response messages. Issue Details: Banning use of anonymous ReplyTo will cause many implementations of WS-Addressing to use a second http connection to communicate the reply or fault. In the case of http bindings, use of anonymous ReplyTo will allow the response to be returned in the http response entity. ws-coord spec design Bob Freund Bob Freund Delete line 619. The proposed resolution was accepted during May 31 - June 01, 2006 (Dublin) F2F meeting. The line 619 "Request messages MUST contain a [reply endpoint] property whose [address] property is not set to 'http://www.w3.org/2005/08/addressing/anonymous' or 'http://www.w3.org/2005/08/addressing/none'." has been removed. Section 5.2, ll.268 - 275. ATAlwaysCapability policy assertion will break AT-policy unaware client. Issue Details: Discussion leading to resolution of 045 underscored the importance of wsp:Optional = true as an "AT policy must understand = false" flag, i.e. its use enables clients which are WS-Policy-aware, but WS-AT-ignorant to access an operation which it is safe for them to use. The same principle should apply to ATAlwaysCapability. If ATAlwaysCapability were used with a wsp:Optional = true attribute, then it's meaning would be: 1) Service has following characteristics and capabilities: it will always execute in a transactional manner; if it receives a transaction context then it will subordinate its transactional behaviour to the transaction represented by that context. 2) Client can access this service if AT unaware 3) Client can access this service if AT aware, but need not send a context 4) Client can send an AT transaction context to this service. In my view this set of meanings is operationally identical to ATAssertion with the wsp:Optional attribute. It is clearly unsatisfactory to have a policy that will break an AT-naive client. But, if we allow ATAlwaysCapability to acquire the optional attribute (or indeed, if we use it in the long form, adjacent to an empty policy alternative) then it just becomes another way of saying MAY flow context. ws-at spec design Alastair Green Alastair Green Remove all references to the ATAlwaysCapability policy assertion type from the WS-AT spec. Closed with no action during August 24, 2006 TC call. i045 WS-AT (cd02) has the following statement on lines - 488-590 "Fault messages MUST include a wsa:RelatesTo header, specifying the MessageID from the Notification message that generated the fault condition." However WS-BA does not include this text. Also, WS-BA includes the following text (lines 406-410): "A notification message is a terminal message when it indicates the end of a coordinator/participant relationship. Closed, Compensated, Canceled, Exited and Faulted are terminal messages as are the protocol faults defined in this specification and in [WSCOOR]." "A notification message is a non-terminal message when it does not indicate the end of a coordinator/participant relationship. Complete, Completed, Close, Compensate, Cancel, Exit and Fault are non-terminal messages." There are no new protocol faults define in WS BA, so the meaning of the text "as are the protocol faults defined in this specification", is confusing. The protocol faults are all mapped onto the soap fault syntax in ws-coord and ws-at, and there are no "protocol faults" defined in ws-ba. However, there is a wsdl one-way operation defined in WS-BA called "Fault". This is not treated as a "protocol fault" defined in this specification, and is not mapped onto the soap fault syntax. This is confusing, and needs to be explained suffiently for comprehension by a new reader. ws-ba spec editorial Tom Rutt Tom Rutt a) Either: Add the missing text which is in WS-AT into WS-BA: "Fault messages MUST include a wsa:RelatesTo header, specifying the MessageID from the Notification message that generated the fault condition." or add a clarification to justify why this requirement is not included in WS-BA. b) Either: change the name of the "Fault" wsdl operation in WS-BA or Add clarificaiton text on why the "Fault" operation in WS-BA is different than a "protocol fault" notification. Fault is a protocol message. To avoid confusion, rename Fault to Fail and Faulted to Failed across all occurences in the specification, including the diagrams. Further, Change line 407 "Closed, Compensated, Canceled, Exited and Faulted are terminal messages as are the protocol faults defined in this specification and in [WSCOOR]" to "Closed, Compensated, Canceled, Exited, NotCompleted, and Faulted are terminal messages as are the protocol faults defined in [WSCOOR]". Proposal 2 was accepted during the August 29-31, 2006 F2F meeting. The description of the Fault message in the CD-02 release states that the message carries a QName indicating the cause of the fault (lines 198/199). The message in the associated schema does not match this description. The ExceptionType defined in the schema contains an ExceptionIdentifier element declared to be a string. The relevant declarations in the schema are quoted in the email . ws-ba ws-ba-schema schema editorial Kevin Conner Kevin Conner Change schema definition such that the ExceptionIdentifier element is a Qname instead of a string. The proposed resolution was accepted during the August 29-31, 2006 F2F meeting. The semantics of Fault and Exit are unclear, and partly overlapping. If the messages are considered in terms of what they mean to the relationship between the parties rather than the internal behaviour, there are three distinct semantics. There should be three messages. Issue Details The present definition of the Fault message is in terms of an internal event ("the participant has failed"); it would be better to define it in terms of the effect on the application contract. However, as it is currently, the Fault message means both "I have not done any of the work you asked me" and "I have failed to undo the work I was told to compensate", depending on when it was sent. There is also a related ambiguity in the use of the Exit message – the text suggests that this could be used to mean both "The application work you asked me to do has no effect" (perhaps because it has already been done) and "I have not done any of the work you asked me to" – which latter is also one of the meanings of Faulted. Application messages would need to be sent to remove the ambiguity. Combining those two, there in fact three semantics : no work, failed work, failed compensation. The semantics should be distinguished, rather than rely on stage of the interaction or application messages. ws-ba spec design Peter Furniss Peter Furniss Create a new message, Refuse, for a participants rejection of the work, and define the semantics of all three: Exit = The application work you asked me to do has no effect : Close, Cancel and Compensate would all leave our business relationship in the same state. Refuse = I have not done any of the work you asked me to. (a spontaneous statement of unwillingness to be part of this activity.) Faulted = I have failed to reach the requested final state Following the pattern for other messages, Refuse would have a Refused reply. Add two new messages CannotComplete and NotCompleted: CannotComplete Upon receipt of this notification, the coordinator knows that the participant has determined that it cannot successfully complete all processing related to the protocol instance. Any work performed by the participant related to the protocol instance was successfully canceled. For the next protocol message, the coordinator should send a NotCompleted notification. After sending the CannotComplete notification, a participant MUST not participate in any further work under that activity. This message may be sent by a participant only from the Active or Completing states. NotCompleted After transmitting this notification, the coordinator may forget about the participant. Upon receipt of this notification, the participant knows that the coordinator is aware that the participant cannot complete all processing related to the protocol instance, and that the participant will no longer participate in the activity; the participant may forget the activity. Proposal 2 was accepted during the August 29-31, 2006 F2F meeting. Refer to state diagrams and tables. A coordinator (or its application) that wishes to just abort the work of an activity, regardless of the state of the participant, will have to send Cancel, and then follow with Compensate if the Cancel crosses with Complete. As a protocol message, the Compensate could be sent immediately, being treated by the participant as it would Cancel if the participant is still active. Issue Details The present spec resolves a cancel/completed collision in favour of the completed, and if the coordinator and its application then determine the participant's work should really be undone, a subsequent compensate is sent. It is possible to imagine use-cases where this pattern is important in an application (for example, if the compensation will involve some penalty charges, which pre-completion cancellation would not). However, in many other cases the intent of the coordinator and its application will be merely to stop and undo if necessary without delay or reconsideration. This could be accommodated without losing the flexibility of the current behaviour if Compensate were allowed to be sent from the Active state, and the receipt by an uncompleted Participant were treated as equivalent to Cancel. ws-ba spec design Peter Furniss Peter Furniss Allow Compensate from Active state, treated as equivalent to Cancel if received in Active state. Closed with no action, during the August 29-31, 2006 F2F meeting. The WS-C/WS-BA protocol combination must carry participant identification information to enable two facilities, without which WS-BA is unworkable for intended use cases: a) Identification of registered and completed Participants, for "checking" purposes b) Identification of Participants for selective cancellation/confirmation when using mixed outcome. A [ParticipantIdentifier] element is required in the WS-C Register message whose value is Participant-defined and which allows the application driving the Coordinator to identify participants from an application standpoint. Typically, this identifier will be returned in an application response, and will also be present in the Register message. This allows the application to correlate application responses (e.g. quote details) and Participants. This feature is required, to take one concrete example, by applications using a WS-BPEL or XLANG-like API, where inner scopes may be compensated selectively, and each such scope is named: compensate scope="foo". The means by which the identifier requirement was avoided for WS-AT (leading to it not being made a base part of WS-C) do not apply to WS-BA, which therefore must provide elements to carry the information. It would not be appropriate to force all WS-BA-using applications to specify application-specific extensions to WS-C just to make WS-BA usable. ws-ba spec design Peter Furniss Peter Furniss Define new element [ParticipantIdentifier] : xs:any (0..1) as an extension field in the Register message, whose use is mandatory when registering with a WS-BA Coordinator. This element's contents are defined by the agent that registers the Participant, and their meaning for the purposes of correlation with application messages that travel between the service and the consuming application is defined by agreement of those two parties, and is not a matter of further concern for the WS-BA specification. (though it would be for anyone specifying a WS-BA api or similar) (Note that this definition is silent on the question of whether the value is application-generated or middleware-generated—this is an implementation issue.) Closed with no action, during the August 29-31, 2006 F2F meeting. WS-BA specification, Section and PDF line number: section 1 , line 35. Reliable recording of state transitions should not be required. Issue Details The statement "All state transitions are reliably recorded, including application state and coordination metadata" should not be required. Making it a requirement imposes unnecessary overhead and is unnecessarily constraining on implementations. WS-BA can perform all of its design goals using presumed abort - i.e. only reliably recording at Completion time (for a participant), at Close time (for a coordinator). Implementation can conform with state tables and interwork seemlessly using presumed abort without observing above requirement. ws-ba spec design Peter Furniss Peter Furniss Delete line 35. Introduction section (line 35), modify as follows: "Appropriate state transitions are reliably recorded, including application state and coordination metadata." Consequent to issue 92 resolution, close this issue with no action. Revert the previously accepted proposal and undo the changes. Proposal 3 was accepted during the October 05, 2006 TC meeting. WS-BA specification, Section and PDF line number: section 3.1, lines 201-202. Definiton of Compensated in 3.1 is wrong. Issue Details The definition of Compensated in 3.1 is "Upon receipt of this notification, the coordinator knows that the participant has recorded a compensation request for a protocol." The other *-ed messages refer to the completion of the processing implied. Since Fault will signal the unsuccessful application of Compensate, the definition, implying Compensated could be sent, then Fault, is bugged. (It is also over-specific on implementation behaviour). Compensated should be sent when the compensation work has been done, not just thought about. ws-ba spec editorial Peter Furniss Peter Furniss Change to send Compensated when the compensation has been processed, not recorded. Issue 073 "Message definitions" will affect the exact text. Issue 85 resolution addresses this. Closed with no action during the August 29-31, 2006 F2F meeting. i073 The message definitions in 3.1 should be defined from the perspective of the sender, not the receiver. Issue Details The message definitions in 3.1 are given from the perspective of the receiver. Although this is appropriate in terms of describing a (one-way) WSDL interface, it really the wrong way round to describe the semantics of the messages. The meaning of a message is better understood in terms of what it says about the sender - who has typically just undergone a state change, rather than what can be inferred by the receiver. Some of the messages are also defined in the glossary - however, cancel and close are there defined as actions, and the others as messages in terms of the sender (as suggested for 3.1). Not all messages/actions are covered in the glossary. ws-ba spec editorial Peter Furniss Peter Furniss Standardize the description of the messages, and in 3.1 express this primarily from the perspective of the sender. Issue 85 resolution addresses this. Closed with no action during the August 29-31, 2006 F2F meeting. i072 At present it is not possible to send Fault in response to Close. (It is possible to send Fault in response to Compensate.) Model requirements such as "quote-to-order" and tentative operations cannot be supported without ability to fault closure. Issue Details: There are many examples of scenarios where completion of an activity involves additional application work in a participant, just as cancellation requires compensatory work. The model section of the spec refers to the following iconic case: " Allow a business application to select which child tasks are included in the overall outcome processing. For example, a business application might solicit an estimate from a number of suppliers and choose a quote or bid based on lowest-cost." A natural application of WS-BA in this scenario is: Buy-side sends Request For Quote (RFQ) with BA context to sell-side. Sell-side sends Completed ("prepared") to coordinator, and responds with Quote to buy-side. Quote is "firm": it will be honoured if quote becomes order. Buy-side likes quote and wants to execute order, so sends Close (no need to send application Order message). As with compensations, the "react to Close" application operation effectively invoked by sending Close is capable of failing (business exceptions will be raised). The most likely reason here is that the quote has timed-out. A failure of this kind should be signalled in response to the Close message. Any scenario where participants move through application states "Pending" to "Final" requires this feature. ws-ba spec design Alastair Green Alastair Green Please see the document uploaded in November for the changes required for Participant completion: The version of the state table in the uploaded document has the old orientation of states and messages, but the point still stands. Closed with no action during the August 29-31, 2006 F2F meeting. WS-BA specification, Section 2, "Using WS-Coordination". Meaning of creating a new context against an existing, current context is not described or defined. Issue Details: WS-C places responsibilty on referencing specs to define meaning of use of current context in CreateCoordinationContext. BA is currently silent on this. ws-ba spec editorial Alastair Green Alastair Green Define meaning of interposition for atomic and mixed outcomes. See email. Proposal 2 was accepted during the August 29-31, 2006 F2F meeting. Long-lived activities are susceptible to message thrashing (retries that are soliciting answers which will not come for a long time). It is useful for a party to be able to indicate that it will not send a message to its counterpart for some period of time. Issue Details: WS-Addressing pre-defined faults cannot be assumed to be deliverable. The WS-Addressing fault that enables indication of postponed response is a reply, and cannot be sent spontaneously. A new message is needed at the WS-BA level, to permit the semantic "Do not expect anything further from me for at least n seconds" to be communicated. This message is a legitimate response to any protocol message that will induce a conversational response. ws-ba spec design Alastair Green Alastair Green Create a new WS-BA non-terminal message NextMessageDelay with a property AnticipatedDelay, value of 0 equals indefinite, positive integer value equals seconds to anticipated transmission of next "real" message. This message is a hint, the anticipated delay may be foreshortened or exceeded in practice at the sender's will. This message may be sent by either the Participant or Coordinator, and may be sent at any time, and is therefore always a legitimate response to any notification that expects a reply. Closed with no action during the August 29-31, 2006 F2F meeting. Section 4.2 "Completion Protocol"; Section 9, "Use of WS-Addressing Headers". A client that initiates a transaction using WS-Coordination CreateCoordinationContext can do so using one-ways, or the anonymous back-channel. The latter facility was added to permit "thin clients" (ones that cannot listen for inbound messages) to initiate an activity. Such a client is likely to have responsibility for terminating the transaction, and it would therefore be appropriate to make the completion protocol have the same characteristics. Issue Details: An interoperable client program is very likely to wish to conduct the following sequence of actions: a) send CreateCoordinationContext to the Activation Service of a Coordination Service. b) send Register for the AT Completion Protocol to the Registration Service of a Coordination Service. c) send AT Completion Protocol Commit or Rollback to the Coordinator for the activity within the Coordination Service. It was accepted at the Dublin F2F that activities a) and b) should be allowed to use the anonymous back channel for the CCCResponse and RResponse replies, allowing the client program to be a thin client, i.e. one that is unable to listen for unsolicited inbound messages. It seems illogical to prevent a thin client conducting all three of the actions in this common sequence. The inability to do c) is likely to vitiate the purpose of the accepted change allowing such a client to enact a) and b). ws-at spec design Alastair Green Alastair Green Specify that WS-AT Completion Protocol has the same addressing characteristics as WS-Coordination, i.e. that the [reply endpoint] property is used to indicate the target of the expected response, and that that endpoint reference is permitted to have the WS-A anonymous URI as its URI. Closed with no change during August 10, 2006 TC call. WS-AT specification, Section 10, 2PC State tables. There is no internal event that models the issue of Rollback to a Participant when another Participant delivers Aborted, thus causing the transaction to abort. Issue Details A coordinator on receiving Aborted from one Participant when in Active or Preparing should initiate rollback to all participants. But the state table just causes that one CV to initiate action Forget and transit to Aborting. The only internal event in the CV table which would send Rollback to the other participants at that point is Expires times out. (this used not be the case, since User Rollback did to). The Participant table does have an action "Initiate Rollback" which is what we need. ws-at spec editorial Peter Furniss Peter Furniss A) Add an internal event to CV table "Initiate Rollback", and add this as an action in the Aborted/Active and Aborted/Preparing cells. The internal event Initiate Rollback causes Send Rollback, Aborting in Active and Preparing states, and is ignored in Aborting, can't happen in Committing. (it is an interpretation rule that the actions and state transitions of a cell complete before any initiated internal events occur - consequently the CV state for the participant from which Aborted was received will be in Aborting when the Initiate Rollback is actioned, and will not be sent Rollback, which aligns with the state diagram.) A stylistic change would then be to make Expires Times Out use Inititate Rollback, rather than do the work for itself (since Expires Times out is "node-wide", it could be left as it is, but it's generally neater to reuse something that is already there, thus, additionally: B) Change the Expires Times Out/Active and /Preparing to action Initiate Rollback, staying in the same state. See email . Proposal 2 was accepted during August 24, 2006 TC call. i036 i048 WS-AT specification, Section 10, 2PC CV State table. Readonly leaves the coordinator in Active state which will cause it to send protocol in reaction to internal events, contrary to the state diagram. Issue Details A coordinator receiving ReadOnly from a Participant should end the protocol exchanges. However, the table currently has the state staying in Active (The "Forget" action has to be understood as initiating forget, as the transitions to None are distinct). If User Commit or User Rollback are received while this state engine is still in the Active state, the table says Prepare or Rollback would be sent. ReadOnly needs to move the state to one where User Commit and User Rollback are ignored. A related problem is the two User actions are not permitted in Aborting - which is correct since we would not allow duplicate User Rollback, but incorrect if the transition to Aborting was caused by the spontaneous arrival of Aborted in Active state. ws-at spec editorial Peter Furniss Peter Furniss Add a state "Forgetting", which is entered by all cells that have Forget as an action. All incoming messages have action Ignore, except for Prepared, and User Commit, User Rollback, Initiate Rollback, Expires Times Out are all ignored. All Forgotten causes transition to None. receive Prepared/Forgetting has action (re)Send Rollback. See email . Proposal 2 was accepted during August 24, 2006 TC call. i036 i048 WS-AT specification, Section 10, 2PC CV State table. It is inconsistent to initiate forgetting on receiving Prepared in Aborting state. Issue Details It is inconsistent that the Prepared/Aborting cell initiate Forgets - a participant that has already gone prepared should not be forgotten until a response is received to the Rollback. Although it is safe to forget about participants when rollback is sent to them, it makes no sense to start forget only when Prepared is received. ws-at spec editorial Peter Furniss Peter Furniss Make the action in Prepared/Aborting to be just Resend Rollback, and keep the state in Aborting. The proposed resolution was accepted during August 24, 2006 TC call. i036 i048 WS-AT specification, Section 10, 2PC CV State table. The existing coordinator view table has an "All Forgotten" internal event that usually causes a transition to None. Issue Details Given the understanding that None means there is no longer any knowledge of the participant, there are three rather different kinds of event that cause transition to state None: a) the knowledge of this particular participant has gone as a result of the Forget action, but knowledge of other participants may remain. b) the knowledge of all participants has gone as a result of Forget for all of them. c) the knowledge of this participant (and perhaps some others) has gone as a result of a crash (when there was no persistent information for it). The "All Forgotten" action is named for event b) (perhaps including knowledge loss after crash), but given the purpose of the state table as referring to an individual C:P relationship, it is actually its a) and c) that are important. The volatile/durable distinction, and the possibility that a readonly participant is forgotten early mean that the completion of forgetting should relate to the single relationship, not the whole node. By separating out the Forgetting state as proposed in issue (new: WS-AT: Forgetting state needed), event a) will now only occur from state Forgetting. It thus becomes unnecessary to consider what is happening to other state machines (to do so would be to impose on implementation, anyway). For event c), forgetting due to crash, requires different behaviour for durable and volatile. The forgetting (= transition to None) can occur from any state except where there is a commit log. By disallowing a transition to None from the Committing state for a Durable partner it is possible to capture the logging requirement without having to describe at all how it is met. All Forgotten as event name is misleading, as it implies volatile and durable behave the same, which is incorrect. ws-at spec editorial Peter Furniss Peter Furniss Replace the All Forgotten internal event by two events: Internal event "Forget Completed", permitted only in state Forgetting, where it causes a transition to None. Internal event "Forgotten by accident" which models transitions to None from all states except Committing, where it is disallowed for Durable, but transitions to None for Volatile. Note that "Forgotten by accident" is an event imposed on an implementation rather than done on purpose. See email . Proposal 2 was accepted during August 24, 2006 TC call. i036 i048 A Participant in Completed state that has had to finalise the application information should be permitted to send Closed or Compensated immediately, rather than wait to respond to the instruction from the coordinator. Issue Details Services involved in loosely-coupled business activities, of the sort targeted by WS-BA are commonly more-or-less autonomous. They are cooperating in the Business Activity, but there are other drivers and requirements on their behaviour. This applies whether the systems involved in the Business Activity are from different organizations (where the autonomy is obvious) or are just different applications in one organization (where legacy applications, for example, often have other, primary goals, and the Business Activity is an integration). Consequently, it must be expected that services will reserve the right to make and apply their own decision to the work they are responsible for, despite their promise to await the decision of the controlling application. This is analogous to a heuristic decision in a classic ACID transaction, but is likely to be more common. Since such an autonomous decision will threaten, and may (like a heuristic decision) destroy the consistency target that led to use of WS-BA, it is important that it can be signalled as soon as possible. If the warning arrives in time, it is possible (given that Business Activities may be long-running) that the controller can cope with the decision – either cancelling/compensating the whole activity, or ensuring that the rebellious participant is accommodated somehow. (This is especially likely with participant-completion) At present, WS-BA does not give a chance for the participant to report an autonomous decision, until it is informed of the coordinator's decision. Since WS-BA is based on one-way messages it would seem fairly straightforward to allow the participant to reply before it is asked. If the answer is "right", the protocol completes with this pre-emptive reply; if it is "wrong", the relationship goes into the normal Fault/Faulted exchange. ws-ba spec design Peter Furniss Peter Furniss Allow Closed and Compensated to be sent by a Participant from Completed state, triggering transitions to new states ("Auto-closed", "Auto-compensated"). If the "right" message arrives - i.e. Close or Compensate, respectively - resend the Closed or Compensated and transition to Ended. (The resend may not be needed - the earlier message may be perceived at the coordinator as the reply, but resending avoids forcing the coordinator to remember the first message) If the "wrong" message arrives (i.e. Compensate in Auto-closed, Close in Auto-compensate), send Fault and transit to Faulting, awaiting Faulted as usual. At the coordinator, receipt of Closed or Compensated in Completed state causes no action and remains in the same state. It is not "ignored", because this is the trigger for the coordinator/application to do something about the situation, but there is no mandated protocol action. Receipt at the coordinator of Closed or Compensated in the wrong state (Compensating, Closing) is ignored - a Fault message will arrive later. (It is not worth complicating matters further by allowing a pre-emptive Faulted, thought it would work.) Closed with no action during the August 29-31, 2006 F2F meeting. i074 The RPC portTypes defined in wsat.wsdl are optional and not useful for interoperability. These are the portTypes defined under: <!-- Optional Syncronous RPC Port Types --> Issue Details Since the RPC portTypes are not useful for interoperability, they are not useful at all and should be removed from the WSDL. These date back to a time before the current state tables were defined and are not compatable with the messages defined in the state table. Given that the purpose of the specification is WS-AT interoperability, the only portTypes the AT WSDL should define are the Mandatory Asynchronous Messaging PortTypes. ws-coord-wsdl ws-at-wsdl wsdl editorial Ian Robinson Ian Robinson Remove the optional RPC portTypes defined in wsat.wsdl i.e those defined under: <!-- Optional Syncronous RPC Port Types --> Also remove from the wsat.xsd the types defined specifically for the RPC portTypes. Specifically the types Vote, PrepareResponse, Outcome and ReplayResponse. In wsat.wsdl, remove the section "Optional Synchronous RPC Port Types" and rename the section "Mandatory Asynchronous Messaging PortTypes" to "Asynchronous Messaging PortTypes". In wscoor.wsdl, remove the section "Mandatory Asynchronous PortTypes" and rename the section "Optional Synchronous RPC Port Types" to "Request/Reply PortTypes". proposal 2 was accepted during August 10, 2006 TC call. Consistent with resolution to issue 56, the Completion protocol diagram should show the coordinator generated aborted transition from Active to Ended state. ws-at spec editorial Ram Jeyaraman Ram Jeyaraman In the Completion protocol diagram add a coordinator-generated transition from Active to Ended state. Label the transition "Aborted". The proposed resolution was accepted during August 10, 2006 TC call. i056 It is fundamentally important for interoperability that the BA specification provide a clear definition of the semantics of each protocol message, in order to establish the precise state management guarantees that must be provided by a conformant implementation. For example, the current definition of Compensated does not indicate that the participant should actually complete its compensation efforts before sending the message. For a participant to return this message, all it has to do is record a compensation request. It is not clear what has happened or will happen to the work that needs to be compensated. As another example, the current definition of the Exit message does not clearly state what happened to the work performed by the participant prior to exiting. Was the work successfully cancelled? Or perhaps no work was performed at all? Similarly, other protocol messages need to be reviewed to ensure that specific guarantees are provided. ws-ba spec design Ram Jeyaraman Ram Jeyaraman Modify the message definitions as follows: The coordinator accepts: Completed Upon receipt of this notification, the coordinator knows that the participant has successfully completed all processing related to the protocol instance. For the next protocol message the coordinator should send a Close or Compensate notification to indicate the final outcome of the protocol instance. After sending the Completed notification, a participant MUST not participate in any further work under that activity. Fault Upon receipt of this notification, the coordinator knows that the participant has failed during the Active, Completing or Compensating states; the state of the work performed by the participant is undetermined. For the next protocol message the coordinator should send a Faulted notification. This notification carries a QName defined in schema indicating the cause of the fault. Compensated After transmitting this notification, the participant may forget about the activity. Upon receipt of this notification, the coordinator knows that the participant has successfully compensated all processing related to the protocol instance; the coordinator may forget its state about that participant. Closed After transmitting this notification, the participant may forget about the activity. Upon receipt of this notification, the coordinator knows that the participant has finalized the protocol instance successfully; the coordinator may forget its state about that participant. Canceled After transmitting this notification, the participant may forget about the activity. Upon receipt of this notification, the coordinator knows that the participant has successfully canceled all processing related to the protocol instance; the coordinator may forget its state about that participant. Exit "Upon receipt of this notification, the coordinator knows that the participant will no longer participate in the business activity, and any work performed by the participant related to the protocol instance was successfully canceled. For the next protocol message the coordinator should send an Exited notification. This message may be sent by a participant only from the Active or Completing states." The participant accepts: Close Upon receipt of this notification, the participant knows the protocol instance is to be ended successfully. For the next protocol message the participant should send a Closed notification to end the protocol instance. Cancel Upon receipt of this notification, the participant knows that the work being done has to be canceled. For the next protocol message, the participant should send a Canceled message. A Canceled message should be sent by the participant if the work is successfully canceled; this also ends the protocol instance. Compensate Upon receipt of this notification, the participant knows that the work being done should be compensated. For the next protocol message the participant should send a Compensated notification to end the protocol instance. A Compensated message should be sent by the participant if the work is successfully compensated; this also ends the protocol instance. A Fault message should be sent by the participant if the work was not successfully compensated. Faulted After transmitting this notification, the coordinator may forget about the participant. Upon receipt of this notification, the participant knows that the coordinator is aware of a fault and no further actions are required of the participant; the participant may forget the activity. Exited After transmitting this notification, the coordinator may forget about the participant. Upon receipt of this notification, the participant knows that the coordinator is aware the participant will no longer participate in the activity; the participant may forget the activity. Further, the following statement in the Introduction section of the specification should be modified from: "All notifications are acknowledged in the protocol to ensure a consistent view of state between the coordinator and participant." to "All non-terminal notifications are acknowledged in the protocol to ensure a consistent view of state between the coordinator and participant. A coordinator or participant may retry sending notifications in order to achieve this." See email. Proposal 2 was accepted during the August 29-31, 2006 F2F meeting. The specification allows a participant to send a Fault message while in Active state. Similarly, it is conceivable that a participant may send a Fault message while in Canceling state. ws-ba spec design Ram Jeyaraman Ram Jeyaraman Allow a participant to send a Fault response to Cancel message. The figures at line 245 and 268 should show a state transition resulting out of a Fault notification from Canceling state. The message definitions should be modified as follows: Cancel Upon receipt of this notification, the participant knows that the work being done has to be canceled. For the next protocol message, the participant should send a Canceled or Fault message. A Canceled message should be sent by the participant if the work is successfully canceled; this also ends the protocol instance. A Fault message should be sent by the participant if the work was not successfully canceled. Fault Upon receipt of this notification, the coordinator knows that the participant has failed during the Active, Canceling, Completing or Compensating states; the state of the work performed by the participant is undetermined. For the next protocol message the coordinator should send a Faulted notification. This notification carries a QName defined in schema indicating the cause of the fault. The state table (line 513) ParticipantCompletion/Participant View/Outbound Events/: {Fault, Canceling} cell should be: (empty, Faulting) The state table (line 528) CoordinatorCompletion/Participant View/Outbound Events/: {Fault, Canceling} cell should be: (empty, Faulting). The proposed resolution was accepted during the August 29-31, 2006 F2F meeting. Consistent with resolution to 66, rename Fault to Fail. PDF line number: lines 152-155. The BA specification states the following: "A coordination context may have an Expires attribute. This attribute specifies the period, measured from the point in time at which the context was first received, after which a long-running activity may be terminated solely due to its length of operation. A participant could terminate its participation in the long running activity using the Exit protocol message." This definition does not explain how the timeout composes with the complete/completed messages. One would presume that, like the two-phase-commit protocol, the timeout ceases to apply when the activity enters the Completed state. By not constraining this particular behavior, BA opens itself up to something along the lines of heuristic decisions, justified on the basis of timeout interpretations. ws-ba spec design Ram Jeyaraman Ram Jeyaraman Reword the definition of 'Expires' as follows: "A coordination context may have an Expires attribute. This attribute specifies the period, measured from the point in time at which the context was first created or received, after which a long-running activity may be terminated solely due to its length of operation. From that point forward, the coordinator may elect to unilaterally compensate the transaction, so long as it has not made an outcome decision. Similarly a participant may elect to exit the activity so long as it has not already decided to complete." See email. Proposal 2 was accepted during the August 29-31, 2006 F2F meeting. PDF line number: lines 233-242. The specification states that: All state transitions are reliably recorded, including application state and coordination metadata. However, the description of GetStatus message states: "If the participant has failed and forgotten the activity the Status response will be wsba:Ended, which must be treated by the coordinator as a failure condition." The fact that a participant may forget an activity due to a failure would appear to contradict the assumption that all transitions are reliably recorded, which violates the 'presume nothing' assumption of the protocol. ws-ba spec design Ram Jeyaraman Ram Jeyaraman Reword the description of GetStatus message from: "If the participant has failed and forgotten the activity the Status response will be wsba:Ended, which must be treated by the coordinator as a failure condition." To: "If the participant has forgotten the activity, the Status response MUST be wsba:Ended." Further, line 234 (description of GetStatus) states: "In response the coordinator or participant returns a Status message containing a QName indicating which row of the state table [Appendix A: State Tables for the Agreement Protocols] the coordinator or participant is currently in." The word 'row' should be changed to 'column' in the above text. The proposal resolution was accepted during the August 29-31, 2006 F2F meeting. The WS-Coordination, WS-AT, and WS-BA specifications provide bindings for SOAP 1.1 and SOAP 1.2. However, the specifications do not include the namespace for SOAP 1.1, and the references section does not mention SOAP 1.1. The specifications should provide references to both SOAP 1.1 and SOAP 1.2. ws-coord ws-at ws-ba spec editorial Ram Jeyaraman Ram Jeyaraman See email . The proposed resolution was accepted during August 24, 2006 TC call. Section and PDF line number: Section 10, CV and P state tables. Following resolution to 081, we are left with two related sub-issues, as discussed in 24/8 TC. This issue aims to scoop these up in one go. 1a. CV now transits directly to None whenever machine Forgets. This enabled removal of All Forgotten row. P table has the same feature (transition to None results from All Forgotten, which is implicitly generated by Forget action). I see no reason not to align P table with this approach. 1b. P table is also inconsistent, internally, and with regard to CV table, in that actions which should lead to None do not say "Forget" except in the case of Commit Decision/Prepared Sucess. 2. Resolution of 081 failed to address the fact that volatile relationships can transit to none through deliberate or accidental amnesia (volatile participants are defined as ones which are not guaranteed to receive the outcome, and either end could therefore decide to wipe its records of the transaction, or could have them wiped by a crash without subseqent recovery). This is not addressed in the state tables, which only allow transition to None through transmission/reception of the past participle messages. ws-at spec design Alastair Green Alastair Green 1. Relabel P table row All Forgotten as "Read Only Decision" and change the Committing/Aborting columns in that row to "N/A". 2. Option A. All P table cells that cause a Send X, which then leads (directly/indirectly) to None, should contain a final action Forget, and should uniformly show a state transition "None". E.g. "Send Read Only and Forget"; "Send Aborted and Forget". 2. Option B. Remove action Forget from CV and P tables, and ensure that all final actions which lead to None show that explicitly without indirection through All Forgotten (as per 081 and resolution of this issue, 1. above). This would be more consistent with resolution of this issue, 3. below. 3. Add a new row to both CV and P tables, following Max's suggestion, called "Volatile Forgotten". All cells are "N/A" apart from Committing/Aborting. These should read "None". [NOTE: Volatile Forgotten (which will not be formally defined, in line with a prior TC decision) is taken for the purposes of this resolution to mean: "The coordinator view ! participant implementation is free to forget a bilateral relationship where the participant is volatile, either through positive action or post-crash amnesia, once the relationship is successfully prepared, as there is no obligation to deliver the outcome to volatile participants. The action or fact of forgetting in this way is represented by the internal event Volatile Forgotten." For the avoidance of doubt, this definition is not part of the proposed resolution.] This issue has been resolved as per the tables (lines 518-522) in the public review draft of the AT specification. This resolution was accepted during August 29-31, 2006 F2F meeting. i081 Section and PDF line number: Section 10, CV state table. CV table, allows Commit Decision in Preparing. This makes it possible for the CV to proceed to a commitment, before the participant has replied, leading to an inconsistent result. It clearly should not be possible for CV to get to PreparedSuccess *with respect to this participant* until it has received Prepared *from this participant*. ws-at spec design Peter Furniss Peter Furniss Add a state ("Prepared") to CV table, entered only from Prepared/Preparing. CommitDecision/Preparing becomes N/A. Prepared cells for incoming messages are as for PreparedSuccess (with no state change). Prepared has N/A for all Internal Events except Expires Times Out, Rollback Decision and Commit Decision, where it has the same entries as Preparing has currently. (Comms Times Out is deemed "not to happen", because a reply has been received). This issue has been resolved as per the CV table (line 518) in the public review draft of the AT specification. This resolution was accepted during August 29-31, 2006 F2F meeting. WS-BA does not state a 'presume compensate' assumption. ws-ba spec design Thomas Freund Thomas Freund After line 73 insert: In the absence of outcome information for a transaction the transaction is presumed to have compensated. State Table change: The state table (line 520) ParticipantCompletion/Coordinator View/Inbound Events/: {Completed, Ended} cell should be: (Send Compensate, Ended). The state table (line 530) CoordinatorCompletion/Coordinator View/Inbound Events/: {Completed, Ended} cell should be: (Send Compensate, Ended). Close this issue. Update issue 71 as described in email. Proposal 2 was accepted during October 05, 2006 TC meeting. Section and PDF line number: 249- 253. WS-BA specification currently states the following: "The coordinator can enter a condition in which it has sent a protocol message and it receives a protocol message from the participant that is consistent with the former state, not the current state. In this case, it is the responsibility of the coordinator to revert to the prior state, accept the notification from the participant, and continue the protocol from that point. If the participant detects this condition, it must discard the inconsistent protocol message from the coordinator." In the case of Participantcompletion, the Cancel/Completed race condition is resolved in favor of the participant. That is, the coordinator will transition its internal state for the participant to Completed, and send forth a Compensate or Close message. The specification is not clear which message (Compensate or Close) is appropriate in this case; or is only Compensate the appropriate one. The spec should provide some guidance. Given that the coordinator had previously sent a Cancel, it seems logical to send a Compensate (upon receiving Completed). However, one may argue that the coordinator may have changed its mind, and hence, Close is quite a valid message to be send (upon receiving Completed). ws-ba spec design Ram Jeyaraman Ram Jeyaraman This issue was closed with no action during October 05, 2006 TC meeting. WS-BA State Table Errata. ws-ba spec design Thomas Freund Thomas Freund See email. The proposed resolution was accepted during October 05, 2006 TC meeting. There is a typo in the state tables of the recent BA document. Section C2, outbound event Cancel/state Active contains Canceling-Active but should be Canceling. ws-ba spec editorial Kevin Conner Kevin Conner In the BA state tables, section C2, outbound event Cancel/state Active: Change Canceling-Active to Canceling. The proposed resolution was accepted during October 19, 2006 TC meeting. The wsba:Failing-Completing state has been omitted from the enumeration in the schema document. ws-ba-schema schema editorial Kevin Conner Kevin Conner Add wsba:Failing-Completing to the enumeration in wsba.xsd. The proposed resolution was accepted during October 19, 2006 TC meeting. See email . ws-coord spec editorial Ram Jeyaraman Ram Jeyaraman See description section above. The proposed resolution was accepted, along with comments as noted in the minutes, during October 19, 2006 TC meeting. 1. The WS-Addressing schema is imported in both wsat.wsdl and wscoor.wsdl, though types from this schema are not used in either WSDL. The imports could each be removed. 2. Further, the wsa:Action extension is in the WS-Addressing namespace instead of the WS-Addressing WSDL Binding namespace in each document. (wsa:Action has been changed to wsaw:Action; this changed from the submitted version where they were in the same namespace). The namespace should be changed to http://www.w3.org/2006/05/addressing/wsdl and it would be nice to use the conventional "wsaw" prefix. 3. Check the copyright notices in XSD/WSDL files, and reconcile them with the copyright notice in the corresponding specifications. ws-coord-schema ws-coord-wsdl ws-at-schema ws-at-wsdl spec editorial Ram Jeyaraman Ram Jeyaraman See description section above. The copyright of the WSDL documents are to be updated as described in the email . Issue 104 has been opened to address the other aspects of this issue. This resolution was accepted during October 19, 2006 TC meeting. i104 WS-Coordination implies in section 7 that [action] values are put in messages. But in line 88, the text "if an action URI is used…". Line 408 says "fault MUST include as the [action] property…". This seems to lead to inconsistency in when an action must appear. ws-coord ws-at spec design Ram Jeyaraman Ram Jeyaraman WS-Coordination, Section 1.5, line 88, remove the phrase "if an action URI is used then". Thus, by enforcing use of wsa:Action uniformly, potential inconsistencies may be avoided. WS-AT, Section 1.3 line 68, the phrase "if an action URI is used then". The proposed resolution was accepted during October 19, 2006 TC meeting. The RDDL documents are missing the OASIS template. For an example of the OASIS template, see http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-rddl-200608.html. ws-coord-rddl ws-at-rddl rddl editorial Ram Jeyaraman Ram Jeyaraman See description section above. The proposed resolution was accepted during October 19, 2006 TC meeting. Section 4.2: What exactly does "Invalid Protocol" mean? When is it sent? The explanation is unclear. ws-coord spec design Ram Jeyaraman Ram Jeyaraman Remove the fault. Change fault description to: This fault is sent by either the coordinator or a participant to indicate that the endpoint that generates the fault received a message which is invalid for the protocols supported by the endpoint. This is an unrecoverable condition. Proposal 2 was accepted during November 07-09, 2006 F2F meeting. See email . ws-at spec editorial Ram Jeyaraman Ram Jeyaraman See description section above. The proposed resolution, along with amendments as recorded in the minutes of November 02, 2006 and November 07-09, 2006, meetings, was accepted during November 07-09, 2006 F2F meeting. Section and PDF line number: Section 3.2, line 331; Section 6, line 572. The resolution to issue 28 included: 3. Change all instances of "reference properties" to "reference parameters" and "ReferenceProperties" to "ReferenceParameters". On review of the PR spec there remain 2 instances where we still refer to "reference properties". ws-coord spec editorial Ian Robinson Ian Robinson In Section 3.2, line 331; Section 6, line 572, change the instances of "reference properties" to "reference parameters". The proposed resolution was accepted during November 07-09, 2006 F2F meeting. i028 Issue i099 properly noted that the WSDLs incorrectly used the "wsa" rather than the "wsaw" namespace for the message "action" attribute. While changing to the "wsaw" namespace is technically correct it may be premature in that the WS-Addressing WSDL binding spec is not yet a Proposed Recommendation and the wsaw namespace is likely to change. Since there is no requirement to specify a wsaw:action attribute in the WSDL, we can isolate ourselves from a dependency on the not-yet-stable wsaw namespace by removing this attribute and the import of the schema for the wsaw namespace. The specifications already normatively define the action URI that MUST be used in protocol messages. Having said that, the normative definition could be made clearer than it currently is. The text (for example in the WS-C spec) says: The action URI MUST consist of the coordination namespace URI concatenated with the '/' character and the element name. For example: http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register It may not be clear what "element" refers to here. Also, the action URIs for faults do not follow this pattern as there is no message element part of the URI. Instead each spec defines a specific action URI to be used for all protocol faults defined for that spec. For example, WS-C says: WS-Coordination faults MUST include as the [action] property the following fault action URI: http://docs.oasis-open.org/ws-tx/wscoor/2006/06/fault ws-coord ws-at ws-ba spec editorial Ian Robinson Ian Robinson 1. Remove the wsaw:Action attribute and xsd:import of the wsaw namespace from each WSDL. 2. In each spec, move the text in the "Namespace" section that begins "The action URI MUST consist of..." to the section "Use of WS-Addressing Headers" and and change the wording to: Request and reply messages used in WS-Coordination MUST include as the [action] property an action URI that consists of the wscoor namespace URI concatenated with the "/" character and the element name of the message. For example: http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register or Notification messages used in [WS-AtomicTransaction | WS-BusinessActivity] MUST include as the [action] property an action URI that consists of the [wsat | wsba] namespace URI concatenated with the "/" character and the element name of the message. For example: http://docs.oasis-open.org/ws-tx/wsat/2006/06/Commit This is clearer about which "element" we are referring to. The definition of the fault action URI can be left exactly as is. The proposed resolution was accepted during November 07-09, 2006 F2F meeting. i098 i099 The Public Review Draft of WS-AT references 3 standard faults in the State Tables in Section 9. Two of those faults are also referenced in Section 9 prose and their definitions exist in Section 5.1 and 5.2. What are the implementation requirements surrounding these standard faults? A similar question exists for WS-BA. Standardizing fault generation may increase in importance for the compensating transaction model, as that defined in WS-BA. Note, only WS-AT is addressed here. It is logical that guidance on standard fault usage should come in WS-AT (and WS-BA as appropriate) rather than WS-C. For WS-AT, two questions are important for discussion: * The requirements surrounding the use of standard faults in Section 9 in prose and the State Tables (and as supported in WS-C and WS-AT, Section 5.1 and 5.2) * Links to WS-C where those standard faults are defined, particularly those currently used in WS-AT. ws-at spec editorial Monica Martin Monica Martin Consider in Section 9 "State Tables", WS-AT: Change from: 503 ... Unexpected protocol messages will result in a fault 504 message, with a standard fault code such as Invalid State or Inconsistent Internal State. Change to: 503 ... Unexpected protocol messages SHOULD result in a fault 504 message. Such fault messages include those standard fault codes defined in [WS-COOR] and found earlier in Section 5, Transaction Faults. Reason for change: Invalid State fault is currently defined in WS-C but no reference exists in WS-AT to WS-C for that fault (WS-C includes its definition). Therefore, for simplicity, we have opted to realign the sentence and provide the WS-C reference. It is recognized there may be other faults than those specified here, such as those in WS-A. This reasoning was used in the rewording suggested. Any TC decision surrounding the rigor of guidance of the use of standard faults will drive whether or not further statements are made in Section 9, particularly regarding those faults used in the State Tables in that section. Our actions may also be related to any decisions surrounding the RFC 2119 review initiated by Actions #56-58, to part of #097, and to #102. The proposed resolution, along with amendments as noted in the minutes, was accepted during November 07-09, 2006 F2F meeting. i097 i102 At present the only place within the AT and BA specs where a statement is made about the use of SOAP w.r.t propagating a CoordinationContext and the location of that context within a message is in section 4.2 of both specifications during the discussion of WS-Policy assertions. In this section in both specs it's stated that in the presence of an ATAsseration, AtomicOutcomeAssertion, or MixedOutcomeAssertion that: "The transaction MUST be represented as a SOAP header in CoordinationContext format, as defined in WS-Coordination [WSCOOR]." (AT 279-280, BA 386-387 and 399-400). Without any further statement elsewhere in the specs on the use of SOAP to propagate a CoordinationContext or on the location of such a context in a message it could reasonably be inferred that when a policy assertion is present SOAP MUST be used and the CoordinationContext MUST be placed in the SOAP header but when such an assertion is not present the use of SOAP is optional and, irrespective of the use of SOAP, the context may be placed anywhere in the message. ws-at ws-ba spec design Andrew Wilkinson3 Andrew Wilkinson3 To resolve this I propose that a precise statement is made about the required location of a CoordinationContext within a message in section 2 of each specification. Lines 145-146 in the AT spec would be modified to read: "The Atomic Transaction coordination context flows in application messages involved with the transaction and MUST be represented in CoordinationContext format as described in WS-Coordination [WSCOOR]. For application messages that use a SOAP binding the CoordinationContext MUST flow in the SOAP header of the message." Lines 179-180 in the BA spec would be modified to read: "The Business Activity coordination context flows in application messages involved with the transaction and MUST be represented in CoordinationContext format as described in WS-Coordination [WSCOOR]. For application messages that use a SOAP binding the CoordinationContext MUST flow in the SOAP header of the message." In addition to the above changes the description of the three policy assertions should also be amended. I believe there are two alternatives here: a) Modify the assertions to state the requirements more clearly: AT lines 279-280 - final sentence of the description: The transaction MUST be represented in CoordinationContext format, as defined in WS-Coordination [WSCOOR]. For application messages that use a SOAP binding the CoordinationContext MUST flow in the SOAP header of the message. BA lines 386-387, and 399-400 - final sentence of each description: The transaction MUST be represented in CoordinationContext format, as defined in WS-Coordination [WSCOOR]. For application messages that use a SOAP binding the CoordinationContext MUST flow in the SOAP header of the message. b) Remove the final sentence from each of the three descriptions (AT 279-280, BA 386-387 and 399-400) as this is now specified in section 2. The proposed resolution, along with amendments as noted in the minutes, was accepted during November 07-09, 2006 F2F meeting. See email . ws-at spec editorial Monica Martin Monica Martin See description section above. The proposed resolution, along with amendments as noted in the minutes, was accepted during November 07-09, 2006 F2F meeting. i102 See email . ws-at spec editorial Monica Martin Monica Martin See description section above. The proposed resolution, along with amendments as noted in the minutes, was accepted during November 07-09, 2006 F2F meeting. i102 i105 See email . ws-at spec editorial Andrew Wilkinson Andrew Wilkinson See description section above. The proposed resolution, along with amendments as noted in the minutes, was accepted during November 07-09, 2006 F2F meeting. See email . ws-ba spec editorial Thomas Freund Thomas Freund See description section above. The proposed resolution, along with amendments as noted in the minutes, was accepted during January 16-17, 2007 F2F meeting. See email . ws-ba spec editorial Ian Robinson Ian Robinson See description section above. The proposed resolution, along with amendments as noted in the minutes, was accepted during January 16-17, 2007 F2F meeting. See email . ws-ba spec editorial Ram Jeyaraman Ram Jeyaraman See description section above. The proposed resolution, along with amendments as noted in the minutes, was accepted during January 16-17, 2007 F2F meeting. See email . ws-coord ws-at ws-ba spec editorial Ian Robinson Ian Robinson See description section above. The proposed resolution, along with amendments as noted in the minutes, was accepted during January 16-17, 2007 F2F meeting. See email . ws-coord-wsdl ws-at-wsdl ws-ba-wsdl spec editorial Ian Robinson Ian Robinson See email . The proposed resolution was accepted during February 08, 2007 TC meeting. See email . ws-coord ws-at ws-ba spec editorial Ram Jeyaraman Ram Jeyaraman See email . The proposed resolution was accepted during May 03, 2007 TC meeting. See email . ws-coord ws-at ws-ba spec editorial Ram Jeyaraman Ram Jeyaraman See email . This resolution should be applied to v1.2 version of WS-TX specifications. In addition, cross-references between the three WS-TX specifications should be updated to point to the v1.2 version of the respective specifications. The proposed resolution was accepted during September 21, 2007 TC meeting. See email . ws-at ws-ba spec editorial Ram Jeyaraman Ram Jeyaraman See email . This resolution should be applied to v1.2 version of WS-TX specifications. The proposed resolution was accepted during October 18, 2007 TC meeting. See email . ws-at spec design Mark Little Mark Little See email. Closed with no action during April 03, 2008 TC meeting. See email . ws-coord ws-at ws-ba spec design Martin Chapman Martin Chapman See email . The proposed resolution was accepted via a TC ballot on April 02, 2008.