ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ws-rx] More on i113
- From: Matthew Lovett <MLOVETT@uk.ibm.com>
- To: "Durand, Jacques R." <JDurand@us.fujitsu.com>
- Date: Wed, 26 Apr 2006 10:19:46 +0100
Hi Jacques,
Which version of the tables are you
working from? Issue i096 was recently accepted by the TC, and includes
an updated PDF for the tables. Unfortunately this issue hasn't been folded
into the current working draft.... so you should probably describe your
changes relative to i096 for now. My note to the TC that contained the
proposal for i096 contains both a PDF and the original open office doc,
so it should be quite easy to produce an annotated doc from there.
http://lists.oasis-open.org/archives/ws-rx/200604/msg00011.html
Thanks
Matt
"Durand, Jacques R." <JDurand@us.fujitsu.com>
wrote on 26/04/2006 04:15:10:
> While working on a more detailed proposal for 113, it appears to me
> that these tables need a bit more work than I thought.
>
> (Again I see these tables as more than just accessory:
they are
> necessary to nail down corner cases, and are ultimate ref material
> for developers.)
>
> In addition to items currently in 113, I propose
the following –
> depending on reactions on the mailing list, I would update 113 appropriately:
>
> 1- As mentioned before, for each one of the tables,
events that may
> occur fall in two categories:
>
> (a) those generated by the RM component (e.g.
RMD generates and
> sends a Fault) and under full control of the RM component,
> (b) those “received” from outside , e.g. RMS
gets a Fault message.
>
> for (a) events, it is OK to use “N/A” for
the non-relevant states
> (the RM component has control over generating these events), but we
> cannot just use “N/A” for (b) events, that the RM component must
be
> prepared to handle in whatever state it is in, even if such events
> occur when they shouldn’t. We need to tell what is the effect of
> receiving (b) events in every state (even if most of the times, sate
> remains the same). Can’t just brush it off with N/A…
>
> 2- There are still several TBD values in these
tables – some of them
> are in particular related to the case where, say the RMS, gets a
> fault like “Seq Closed Fault” or “Seq Terminated Fault”, while
RMS
> has not even closed or terminated the Seq (mostly, a decision from
> RMD). I assume an RMS should update to “closed” when getting a Seq
> Closed Fault, even if it has never sent CloseSequence (like it does
> for termination). This has to appear in the table.
> Another case of questionable transition, is the
“Elapse Expires
> duration” event. Should close IMO instead of terminate, as RMS may
> want to be able to query a final Ack.
>
> 3- there are events ( lines) in these tables
that actually do not
> cause any state transition. E.g. in RMS table: “new message”,
> “retransmit of unack message” , “SeqAck (non final)”, “Nack”.
But it
> seems we are interested in reporting what should the RMS behavior
be
> for these in each current state. I’d suggest to do this outside
> these state transition tables, e.g. in another table where we
> consider specific events that do not cause any transition, - but
> need to tell what should the RMS (RMD) behavior be depending on the
> state it is in -, (kind of “decision table”).
>
> Jacques
>
>
- References:
- More on i113
- From: "Durand, Jacques R." <JDurand@us.fujitsu.com>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]