NEW ISSUE: Determine standard fault requirements in WS-AT

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

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