[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 041 - WS-AT: Invalid events should not cause defined transitions
This is identified as WS-TX issue
041. Please ensure follow-ups have a subject line starting
"Issue 041 - WS-AT: Invalid events should not
cause defined transitions". From: Peter Furniss
[mailto:peter.furniss@erebor.co.uk] Issue name -- WS-AT: Invalid events should not cause defined
transitions PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON
THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER. The issues coordinators will notify the list when that has
occurred. Target document and draft: Protocol: WS-AT Artifact: spec Draft: AT spec cd 1 Link to the document referenced: http://www.oasis-open.org/committees/download.php/17311/wstx-wscoor-1.1-spec-cd-01.pdf Section and PDF line number: ws-at section 10, lines 503/505 Issue type: Design/Editorial
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". Issue 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. Proposed resolution 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 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]