[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 107 - Other Editorial Issues Surrounding AI#0057 Review forRFC 2119 (I#097)
This issue is identified as 107. Please use the subject line for future correspondence on this issue: "Issue 107 - Other Editorial Issues Surrounding AI#0057 Review for RFC 2119 (I#097)". -----Original Message----- From: Monica.Martin@Sun.COM [mailto:Monica.Martin@Sun.COM] Sent: Tuesday, October 31, 2006 2:40 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) 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 Issue Description: These editorial items were missed in the RFC2119 review AI#0057 opened as a result of Issue #097, and Issue #102 [1]. This issue addresses those that: 1. Appear to have been missed and may require changes 2. Proposed for change by Wilkinson and further discussion is suggested 3. General - Editorial corrections 1. Appear to have been missed and may require changes Section 3. Change from: 168 Volatile 2PC: Participants managing volatile resources such as a cache should 169 register for this protocol. Change to: 168 Volatile 2PC: Participants managing volatile resources such as a cache 169 register for this protocol. Reason: Alleviate potential confusion by using active voice and deleting 'should. Change from: 170 Durable 2PC: Participants managing durable resources such as a database should 171 register for this protocol. Change to: 170 Durable 2PC: Participants managing durable resources such as a database 171 register for this protocol. Reason: Alleviate potential confusion by using active voice and deleting 'should.' Change from: 172 A participant can register for more than one of these protocols by sending multiple Register messages. Change to: 172 A participant MUST register for more than one of these protocols by sending multiple Register messages. [add] A participant MUST register using one of the protocol identifiers defined in this section. Reason: This would accommodate later references and alleviate the need for multiple MUST conditions. The intent is currently implicit in the specification. This item was missed in the original review and was not a part of I#102. Section 3.2. Change from: 185 A Completion protocol coordinator must be the root coordinator of an atomic transaction. Change to: 185 A Completion protocol coordinator MUST be the root coordinator of an atomic transaction. Reason: Consistent with the probable intent of issue #047. This item was missed in the original review and was not a part of I#102. 2. Proposed for change by Wilkinson and further discussion is suggested Section 8 487 For example, in cases 488 where a Coordinator or Participant has forgotten a transaction that is completed and needs to respond to 489 a resent protocol message, the [source endpoint] property SHOULD be used as described in section 3.3 490 of WS-Addressing 1.0 ? Core [WSADDR] Comment: As indicated by AI#057 suggested change, consider whether a normative requirement is advised in a sentence that is 'for example'. Similar discussions have occurred in the TC past. Suggest this sentence be restructured to correlate to the paragraph in general and reworded. 3. General - Editorial corrections In general, determine the case of each relevant noun is consistent for terms such as Commit, Prepare, etc. in the prose text. =============== [1] This issue assumes the following changes from Issue #102, #097 (AI#057). (I#102) Section 3.3.1. Change from: 212 All participants registered for this 213 protocol must respond before a Prepare is issued to a participant registered for Durable 2PC. Change to: 212 All participants registered for this protocol MUST respond before a Prepare is issued to a participant registered for Durable 2PC. Reason: Clarify the behavior that is expected. Correspondingly, an equivalent constraint later in Section 3.3.2 (line 223) is proposed to upgrade to upper case MUST. (I#102) Change from: 213 Further 214 participants may register with the coordinator until the coordinator issues a Prepare to any durable 215 participant. Change to: 213 Further 214 participants MAY register with the coordinator until the coordinator issues a Prepare to any durable 215 participant. Reason: Consistency with other suggested changes in AIs, #102, etc and preceding change proposed. (AI#057) Section 3.3.2 Change from: 223 All participants registered for this protocol must respond Prepared or ReadOnly 224 before a Commit notification is issued to a participant registered for either protocol. Change to: 223 All participants registered for this protocol MUST respond Prepared or ReadOnly 224 before a Commit notification is issued to a participant registered for either protocol. (I#102) Section 8. Change from: 318 Lines (8-11) are a policy expression that includes an AT policy assertion (Line 10) to indicate that an 319 atomic transaction in WS-Coordination [WSCOOR] format MAY be used. Change to: 318 Lines (8-11) are a policy expression that includes an AT policy assertion (Line 9) to indicate that an 319 atomic transaction in WS-Coordination [WSCOOR] format MAY be used. Reason: Correct to say Line 9 (Line 9 has the wsp:Optional....). Change from: 320 Lines (13-19) are a WSDL [WSDL] binding. Line (17) indicates that the policy in Lines (9-12) applies to 321 this binding, specifically indicating that an atomic transaction MAY flow inside messages. Change to: 320 Lines (13-19) are a WSDL [WSDL] binding. Line (16) indicates that the policy in Lines (8-11) applies to 321 this binding, specifically indicating that an atomic transaction MAY flow inside messages. Reason: Similar correction is required. Line 16 indicates that the policy in lines 8-11.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]