Issue 108 - Other Editorial Issues Surrounding AI#0057 Review forRFC 2119 (I#097), Submission 2

[Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>]

This issue is identified as 108.

Please use the subject line for future correspondence on this issue: "Issue 108 - Other Editorial Issues Surrounding AI#0057 Review for RFC 2119 (I#097), Submission 2".

-----Original Message-----
From: Monica.Martin@Sun.COM [mailto:Monica.Martin@Sun.COM]
Sent: Tuesday, October 31, 2006 4:06 PM
To: Andrew Wilkinson3; ws-tx@lists.oasis-open.org; Ram Jeyaraman
Subject: NEW ISSUE: Other Editorial Issues Surrounding AI#0057 Review for RFC 2119 (I#097), Submission 2

Protocol: WS-AT

Artifact:  spec
Draft:  WS-AT specification PR 01

Link to the documents referenced:
a.
http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/20223/wstx-wsat-1.1-spec-pr-01.pdf

b. See: wstx-wsat-1.1-spec-pr-01.rfc2119.pdf  attached to
http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200610/msg00063.html.
<http://www.oasis-open.org/committees/download.php/20224/wstx-wsat-1.1-spec-pr-01.doc>

Issue type: Editorial

Related issues: I#102, AI#57, I#105 (possible)

Issue Description: These editorial items were noted when evaluating the RFC2119 review AI#0057 opened as a result of Issue #097, and Issue #102 [1]. This issue addresses those that may be require further discussion, as proposed by Andrew Wilkinson, or were identified as a result of those comments.

 1. Proposed by Wilkinson and question raised.
 2. Found as a result of evaluating the proposed changes including 1.

1. Section 2. Proposed by Wilkinson
The Atomic Transaction coordination context MUST flow on all application  messages involved with the transaction.
Change proposed in Line 145: Change "must" to "MUST".

>>Comment: In this section, this is insufficiently defined to propose a requirement. The specification has not yet defined how an "application message is involved in a transaction". This concept is not normatively introduced until Section 4.2. Appropriate normative statement is made on lines 267-269 on conditions that a AT coordination context flows with a
request message.

2. Sections 3.2 and 3.3.3. Found in evaluating 1.
Generally, suggest the TC make a decision as to the intent of Sections 3.2 and 3.3.3, and whether the English prose relates specifically to the diagram, to the state tables that follow in Sections 9.1 and 9.2, or both, and be explicit about that association. The diagrams in both sections (first referenced) are high-level overviews. Yet, the prose that follows may indirectly reference them or the state tables. For example, it is difficult to infer the state that a notification is being
processed within these sections. This could lead to confusion to potential adopters. This can be shown with two examples from Section 3.3.3:

Example 1:
231 The participant accepts:
232 Prepare
233 Upon receipt of this notification, the participant knows to enter phase 1 and vote on the outcome
234 of the transaction. If the participant does not know of the transaction, it MUST vote to abort. If
235 the participant has already voted, it MUST resend the same vote.

Comment: The diagram fails to illustrate receiving "Prepare" in the  "None" state or resending the same vote if receiving the Prepare while the participant is in the Prepared or Aborting state.

Suggestion: The TC determine whether or not normative statements should be made OR the state that the notification was received must be stated for each normative statement. Previously, the TC discussed the normative nature of the state tables. These questions highlight whether or not that question may need redress. It may be advised to explicitly identify these sections as non-normative and defer to appropriate state tables for guidance. For example, the "MUST" on line 235 is state dependent but one can only infer the state, because it is not explicitly stated. The state tables are more precise than prose in these sections (and is acknowledged in text in both sections).

Example 2:
240 Commit
241 Upon receipt of this notification, the participant knows to commit the transaction. This notification
242 MUST only be sent after phase 1 and if the participant voted to  commit. If the participant does
243 not know of the transaction, it MUST send a Committed notification to the coordinator.

Comment: Term "voted to commit" introduces a problem for first MUST above. The term "voted to commit" includes participants that sent either Prepared or ReadOnly. (See lines 245-251 below.) It is uncertain if coordinator should send commit to a participant that voted to commit via notification of ReadOnly. ReadOnly is defined on line 249 as that participant both voting to commit AND it does not wish to participate in phase 2. The state table is clear that commit should not be sent to a participant that voted ReadOnly, just the above prose are unclear and could be misinterpreted.

Suggestion: Only send Commit to participants that notified by Prepared.