Didn’t mean to…
I am comfortable with the rule of the underlying
bindings but not “there are a whole lot of reasons you might not want to actually
transmit a fault”.
My intent was to emphasize that faults
serve valuable resource management and state synchronization purposes in this
protocol. Although it *might* be stable and closed if these faults are not
communicated, I have not examined the cases to determine (or say, convince
myself) that it always will be.
Thanks
-bob
From: Christopher B
Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, June 29, 2006 9:20
PM
To: Bob Freund-Hitachi
Cc: Doug Davis; Marc Goodner;
ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] State Tables
- First June 27 version
Bob,
This
isn't for RM to specify, it is already specified in the relevant SOAP bindings
to specify whether or
where
to transmit fault messages that are generated.
Cheers,
Christopher
Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
"Bob
Freund-Hitachi" <bob.freund@hitachisoftware.com>
wrote on 06/29/2006 08:10:16 PM:
> This protocol, at first impression, needs
that the faults actually
> get transmitted.
>
Otherwise,,,(for example)
> No
create sequence refused fault => RMS times out (unspecified)
> retries(unspecified) and reaches the
conclusion that the RMD is
> dead(unspecified) (p.s. is this returned in
req/resp with a 500 http error?)
>
> No
message rollover fault: RMS keeps sending and keeps requesting
> acks without progress, assumes RMD is
dead(unspecified)
>
> The
faults if transmitted, serve the purpose of defining the
> potential for an error recovery scenario.
> Without
the fault transmission, then the spec lacks recovery
> language. In fact it lacks language to
deal in general with the
> issue of retrys and duplicate protocol
control elements.
> So if
Generate does not imply transmit (see SOAP 1.2 Sec 5.4 Fault
> Message) we have more work to do (perhaps
even if it does)
> Thanks
> -bob
>
>
>
>
> From: Marc Goodner
[mailto:mgoodner@microsoft.com]
> Sent: Thursday, June 29, 2006 1:06 PM
> To: Doug Davis; ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] State Tables - First
June 27 version
>
> Agree
with generate for faults. There are any number of reasons you
> might not want to actually transmit a fault.
>
> From: Doug
Davis [mailto:dug@us.ibm.com]
> Sent: Thursday, June 29, 2006 9:56 AM
> To: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] State Tables - First
June 27 version
>
>
> Bob,
> I like the idea of leaving it blank
(unspecified bad thing) :-)
> As for Xmit, could we not just use the
term "generate" like most
> WS specs since the actual handling of the
fault itself depends on may factors.
> thanks,
> -Doug
>
> "Bob Freund-Hitachi" <bob.freund@hitachisoftware.com>
>
06/29/2006 12:47 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
> I don’t think that it is the wsa layer,
since although it might be
> our intent that CSR be related to its
corresponding CS via wsa:
> RelatesTo, there is nothing that I know that
might prevent a message
> destined to the RM Source endpoint arriving
without such a relation.
> I agree that it is weird and perhaps my
choice might have been
> wrong. I picked unknown sequence fault
since the CSR contains a
> sequence identifier, which is unknown, on the
other hand it might be
> better to use Sequence Terminated fault.
An alternative is to leave
> it blank which is an unspecified bad thing.
> Yes, Reply:to of anon would have the response
return on the back
> channel, Should I use “respond”
instead of “Xmit”? I used Transmit
> since it is in the Glossary which says
“The act of writing a message
> to a network connection” which I
supposed applied to a response
> that might be sync or async with respect to
the nature of the
> underlying wire transport. Perhaps
“Respond” should be defined in
> the glossary
> Comments?
> Thanks
> -bob
>
>
>
>
> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: Thursday, June 29, 2006 8: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
>
> "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]