ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] State Tables - First June 27 version
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Thu, 29 Jun 2006 08:38:40 -0400
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
"Bob Freund-Hitachi"
<bob.freund@hitachisoftware.com>
06/28/2006 06:50 PM
|
To
| Doug Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [ws-rx] State Tables - First June
27 version |
|
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
"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]
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]