Re: [ws-rx] State Tables - First June 27 version

[Doug Davis <dug@us.ibm.com>]

Bob,
 comments about the state tables:

RMS:
 - not sure I see the diff between
"blank" and "N/A".  In both cases its abnormal
behavior.  Take for example the receipt of a CSR w/o sending a CS
- why would being the "none" state be any different from being
in a "closed" state.  Both would require the rejection of
the message and no change in the state.
- On CreateSeqRefused fault - I would
think the action wouldn't be "none" - something more like generate
fault since something needs to tell the AS (or the admin) that the sequence
was refused. But this gets a bit close to leaving our scope.
- For the "Send message" event,
in the "Rollover" state, I wouldn't have said "No action"
in that case I would have said "generate fault" or something
- since I believe you're assuming that the msg numbers got too high, right?
- I think the same is true for the max
msg num reached event too - seem like some fault should be generated instead
of "no action"
- CloseSeq event - Closing state - I
think it should resend the Close message instead of "n/a" since
it may need to resend it.
- CloseSeq event - Closed or Terminating
states - I think those should be blank or N/A since that should never happen
- Terminate Seq [int] event - None state
- I think that should be blank since it shouldn't ever happen
- Terminate Seq [int] event - Connecting
state - I don't think you want to generate a fault since its an internal
event - instead we should just move to the terminating state
- TermSeqRes event - I would think that
all states (except terminating) would either generate some fault or be
blank (since it should never happen) - don't understand why "none"
state is different or why it doesn't generate an UnknownSeq fault.
- Expires - shouldn't this cause some
action for some states?  Like terminate the seq?
 - InvalidAck [msg] event - I think
this highlights some of the inconsistencies I think are in the table -
in the first two states we generate an unkownSeqFault but in other spots
in the table we have either "no action" or blank for similar
"never should happen" cases. We need to be consistent.
- Actually, what is the last row/event?
 is that meant to be InvalidAck Fault?  We don't have an invalid
Ack msg just a fault.  If its supposed to be a fault msg then I don't
see why we would generate an invalid ack fault by receiving this msg.

RMD:
- CloseSeq msg, Closed state -> should
be no action, not xmit SeqClosed fault
- Expires - shouldn't this cause some
action for some states?  Like terminate the seq?
- Non-RM msg event - should be "WSRM
Required Fault" instead of just "WSRM Fault"

thanks,
-Doug

"Bob Freund-Hitachi" <bob.freund@hitachisoftware.com>

06/27/2006 09:52 AM

To	"[WS-RX]" <ws-rx@lists.oasis-open.org>
cc
Subject	[ws-rx] State Tables - First June 27 version

Added references, removed gratuitously applied
protocol fault responses to change them to unspecified.
Corrected a few cells[attachment "wsrm-1.1-spec-wd-15-ith-ST-Edits.doc"
deleted by Doug Davis/Raleigh/IBM]