Re: [ws-tx] Issue 105 - WS-AT: Determine standard fault requirementsin WS-AT

["Monica J. Martin" <Monica.Martin@Sun.COM>]

>Ram Jeyaraman wrote: This issue is identified as 105.
>
>Please use the subject line for future correspondence on this issue: "Issue 105 - WS-AT: Determine standard fault requirements in WS-AT".
>
>-----Original Message-----
>From: Monica.Martin@Sun.COM [mailto:Monica.Martin@Sun.COM]
>Sent: Friday, October 27, 2006 4:59 PM
>To: ws-tx@lists.oasis-open.org
>Subject: [ws-tx] NEW ISSUE: Determine standard fault requirements in WS-AT
>
>Protocol:  WS-AT
>Artifact:  spec
>Draft:  AT specification, Public Review 01
>http://www.oasis-open.org/committees/download.php/20224/wstx-wsat-1.1-spec-pr-01.doc
>(Note: The .pdf was used for this issue but the OASIS sites are
>currently unavailable for a reference)
>  
>
mm1: Update to: 
http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/20223/wstx-wsat-1.1-spec-pr-01.pdf.

>Issue type: design
>Related issues: 097, 102 (at a minimum)
>Issue description:
>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
>
>Proposed resolution:
>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.
>
>Note: At this time, the OASIS sites are unavailable due to maintenance.
>This issue may be updated when the links are available. Thank you.
>  
>
mm1: See update provided above. Thank you.

>
>
>  
>