Agree that I’m still
reviewing this as well. I’m having trouble keeping up with this conversation as
well. It was also difficult to see what the difference between the two copies
posted yesterday was. If there is to be another update to that redlines from
the last post would be appreciated.
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Thursday, June 29, 2006 5:39 AM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] State Tables - First June 27 version
Bob,
still
reviewing but I was thinking about the CSR event/msg and the RMS being in the
None state situation, and I'm not comfortable with it transmitting an
UnknownSeq Fault. I agree that it is an incorrect thing to have happen
but by saying that someone must generate an UnknownSeq Fault may be asking a
bit much. In situations like this we can not be sure which part of the
soap stack will catch this bad situation - the state table is assuming that RM
will be the one. However, it may not be because there are actually two bad
things going on here - one for RM and one for WSA. Its possible that the
WS-Addressing layer could look at the message, notice the wsa:RelatesTo, try to
find a waiting request message to match it up, and finding none just ignores
the message - or generates some other kind of fault. I'd prefer if we put
something else in that box, like N/A. Not a show-stopper, just don't like
the implication on soap stacks that the current entry implies.
The
other part of this that worries me is that the state table says
"Xmit" the fault - and if the CSR came back on a back-channel then it
can't do that. This may go back to the issue of Xmit vs Generate for all
Xmits in the table.
I think
this concern would apply to the other events/msgs that are related to Respone
messages.
thanks,
-Doug
Doug.
It
was very hard for me to make the state table reflect the text that I found and
not what I thought the protocol should do.
I
made a distinction between blank which I thought to be unspecified or invalid
behavior, and N/A which is internal behavior inconsistent in the given state.
The state table is not a general state table for a machine capable of
processing wsrm messages, but rather it is a state table that describes
behavior with respect to the lifetime of a sequence. N/A in general represents
combinations that I thought to be impossible or self inconsistent. An
example of this is the Create Sequence event from an unspecified motivator that
starts the ball rolling. Perhaps in incorrect implementation of an RMS
might have this event occur to a sequence that already exists, but it is not an
event that has any external appearance on the wire and thus has meaning to the
RMS state table only while in the None state.
To
illustrate this distinction take the case of receipt of a CSR while in the None
state. In the None state, there is no knowledge of the sequence, it does
not yet exist, thus I chose to apply the unknown sequence fault due to its
description in Section 4.3, unless message in its context has some sort of
special meaning. In the closed state, the sequence is known, but there is
no text I can find that expresses what should be done. Perhaps, since
this might be an unrecoverable state or protocol error, a Sequence Terminated
fault as described in Sec 4.2 might be appropriate, but the definition of
protocol error exists in only its plain reading but does not otherwise what
messages received at what time constitute such an error.
The
CreateSequenceRefused fault’s reception while in the none state was a close
call. Note that I specified that the fault is dropped with a reference of
unspecified which roughly means that I made it up (my bad). Strictly
speaking, I am not sure that the CSRefused fault contains a sequence identifier
or not since its detail element is only defined as xs:any, so I could not make
up my mind if it was targeted to a sequence or not (*maybe there is a new issue
here*).
If
it is not sequence targeted, then in the none state it could by N/A, but since
it is a potential message from the other side of the wire it could be a
sequence Terminated fault. My error was not leaving this cell as blank
since I don’t this the spec says what should happen here.
One
problem for me as I worked to construct these tables is that we are not very
good at making the distinction of generating a fault and transmitting a fault
message. Many of these ought to be transmitted as fault messages since
efficient state recovery depends to some degree on these fault messages to be
used as signals from one side of the wire to the other. I opened an issue
for more precise statements of source and action for each fault partially due
to this lack of clarity. Perhaps there ought to be a flavor or two of
faults that might be generated but not transmitted for local purposes that can
be used for such circumstances.
-For
Send message in the rollover state the spec does not specify when message
rollover occurs precisely. That is why there a Reached max msg number
internally sourced event. I imagined that if the RMS was in rollover
state for whatever reason, the sequence was going to have to wind down.
We know that the transfer of some prior message was faulted by the RMD or
that the RMS itself determined that the message about to be sent generated a
MessageNumber too high. Anyway, I did not include a section reference
here since there is none describing this situation. We also do not have a
fault that is used to convey such a situation. Perhaps I should have left
this cell blank too and not attempted to make an unreferenced guess about correct
operation. The fix for this cell is to make some text somewhere state
what it should do or to point me to where I missed it which is a distinct
possibility.
-Close
Sequence event. The motivator for close sequence is not specified; indeed
it is an optional concept as indicated by its MAY language from whence I
derived its definition. I think that you caught an error of mine. The
cells should be N/A in Closed and Terminated. I agree that is something
that I should fix. I have some difficulty with this event in the
connecting state, since it is conceivable that the RMS might to close the
sequence at any time and indeed that includes the connecting state where the
RMS has not yet created the sequence (since it is not created until the CSR is
successfully processed and the Sequence ID in known. I think that No
Action [None] might be applied here although it might leave an orphaned
sequence for the RMD to clean up some day. As for CloseSequence
re-transmissions, there is nothing that describes re-transmissions in any
specific way. I don’t think it should be the re-triggering of the close
sequence event. I suspect that especially dur to the new polling stuff
that I might enjoy construction a “MEP” engine that might operate underneath the
Sequence State machine to handle re-transmission and polling.
Re-transmission behavior probably should be moved entirely to that new
state table when we decide it is warranted.
-Terminate
Sequence[int] none state: You there is a problem with this row
Should be N/A | No Action[none] | STET | STET | STET | N/A
In
the connecting state although the RMS may have sent a sequenceID, the RMS has
not yet processed it. It is a valid condition, but the correct next state
is None with no action since there is no sequence yet to terminate. Spec
text might be tightened here. Can you suggest where? * Perhaps some words
that define Sequence Lifetime ought to be included in Sec 3.4*.
-TernSeqRed
event well in the None and Connecting State I guess it ought to be the unknown
seq fault I will fix In the other states other than Terminating I
left it blank since the behavior is unspecified as far as I can determine.
Perhaps this is a good use of SequenceTerminated fault transmission to
the RMS.
-Expires:
you are correct, but the spec doesn’t say. I opened an issue on this one
The
last row is an event raised by the receipt of an invalid acknowledgment range
(see section 4.4) Its tribber is the receipt of any ack range that is
invalid
RMD
-CloseSeq
message, I disagree, according to sec 4.7, the attempt to close a sequence that
is already closed results in this fault.
-Expires:
Yup, where does the spec say what it should do? (issue proposed on this one)
-Non-RM
message: you are correct, I will fix
Thanks
for reviewing
-bob
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Wednesday, June 28, 2006 12:23 PM
To: ws-rx@lists.oasis-open.org
Subject:
Re: [ws-rx] State Tables - First June 27 version
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
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]