OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-rx] More on i113


Durand, Jacques R. wrote:

> Mmmh… I have been using the latest source provided to me by Matt 
> Lovett I believe.
>
the latest state tables, to my knowledge, are in 
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200604/msg00011.html 

Tom Rutt

> Looking quickly at WD12 pdf, the tables are pretty much the same as 
> what I started from – actually even more undetermined (still many “?”)
>
> So the changes I proposed (in red in the RTF) depart indeed enough 
> from the source tables to make it hard to identify the original ;-)
>
> Jacques
>
> ------------------------------------------------------------------------
>
> *From:* Marc Goodner [mailto:mgoodner@microsoft.com]
> *Sent:* Tuesday, May 02, 2006 5:14 PM
> *To:* Durand, Jacques R.; Matthew Lovett
> *Cc:* ws-rx@lists.oasis-open.org
> *Subject:* RE: [ws-rx] More on i113
>
> Actually, I’m looking at this now and it looks like it is using an old 
> version of the state table. I can’t line this up against what is in 
> WD12 at all.
>
> Marc Goodner
>
> Technical Diplomat
>
> Microsoft Corporation
>
> Tel: (425) 703-1903
>
> Blog: http://spaces.msn.com/mrgoodner/
>
> ------------------------------------------------------------------------
>
> *From:* Marc Goodner [mailto:mgoodner@microsoft.com]
> *Sent:* Tuesday, May 02, 2006 3:30 PM
> *To:* Durand, Jacques R.; Matthew Lovett
> *Cc:* ws-rx@lists.oasis-open.org
> *Subject:* RE: [ws-rx] More on i113
>
> Jacques,
>
> Is this document the proposed updates you note below?
>
> View Document Details:
>
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/document.php?document_id=17864
>
> Download Document:
>
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/17864/state-tables-JD-3-diffs.rtf
>
> Marc Goodner
>
> Technical Diplomat
>
> Microsoft Corporation
>
> Tel: (425) 703-1903
>
> Blog: http://spaces.msn.com/mrgoodner/
>
> ------------------------------------------------------------------------
>
> *From:* Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
> *Sent:* Wednesday, April 26, 2006 1:02 PM
> *To:* Matthew Lovett
> *Cc:* ws-rx@lists.oasis-open.org
> *Subject:* RE: [ws-rx] More on i113
>
> Matt:
>
> Most proposed updates (except some in my #2) still apply to your 
> latest tables – will propose a sample of updated tables.
>
> Also propose the following:
>
> - to not " Fault a Fault", e.g. if RMS receives a Message Rollover 
> Fault for an unknown sequence,
>
> it will not complain back with "Unknown Sequence Fault".
>
> - When sequence expires: propose it closes rather than terminates: one 
> must still be able to query
>
> it to get a final Ack.
>
> Thanks,
>
> Jacques
>
> ------------------------------------------------------------------------
>
> *From:* Matthew Lovett [mailto:MLOVETT@uk.ibm.com]
> *Sent:* Wednesday, April 26, 2006 2:20 AM
> *To:* Durand, Jacques R.
> *Cc:* ws-rx@lists.oasis-open.org
> *Subject:* Re: [ws-rx] More on i113
>
>
> 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
>>
>>
>


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]