[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] Issue i096
Paul Fremantle wrote: > Matt > > My firm belief is that the state tables should not "make" any decisions > that are not justified in the text. So I think for every hole or > ambiguity in the tables we need to fix up the text. > Right, I think this is where the tables are quite useful -- to find holes or contradictions in the spec. > I think we should clarify the text to state that the sequence is not > closed or terminated - i.e. it can still accept undelivered messages. Of > course it will not accept new messages. > I'm not sure if that is necessarily the right/only way to view this. If the RMD knows that receiving/delivering messages in the sequence at some point is going to result in a MessageNumberRollover fault, does it make sense for the RMD to continue receiving undelivered messages till it reaches the limit and then fault? -Anish -- > Paul > > > Matthew Lovett wrote: > >> >> Hi Paul, >> >> That's where these tables get interesting. You could argue that there >> are several implementation choices here (keep using the Sequence, >> close it, terminate it) and they could all have their advocates. The >> tables don't have a notation for "implementation detail". Equally we >> could raise the issue you suggest tighten up in the spec to force a >> choice onto implementers. >> >> I'd be happy with you raising the issue, though I'd need to do some >> more thinking about the implications of picking a single choice. I'd >> also be happy to put a footnote into the table to clarify that cell. >> Any suggestions for text? >> >> Matt >> >> >> >> Paul Fremantle <paul@wso2.com> wrote on 05/04/2006 16:25:57: >> >> > Matt >> > >> > Am I right in thinking we need a new issue for the decision you made >> > regarding RMD Rollover? I cannot find any words in the spec describing >> > what is acceptable after rollover. (I know its not that likely, but its >> > twice as likely now as it used to be!). >> > >> > Paul >> > >> > Matthew Lovett wrote: >> > > >> > > Hi Paul, >> > > >> > > The columns that were removed were on the RMD side. In the old table >> > > the author had assumed that if a RMD receives a message with a >> message >> > > number greater than the limit, that it entered a new 'rollover' >> state. >> > > I don't believe that state added any value, and don't think that the >> > > main spec mentions, implies or defines it. Having reached that >> > > conclusion I nuked the entire column ;) The state transition that >> now >> > > occurs is that a fault is returned to the sender, but that the RMD is >> > > still in the 'Connected' state, so the RMS may continue to retransmit >> > > earlier messages. >> > > >> > > The majority of the RMS changes are to ensure that each cell contains >> > > both an action and a next state, as the gaps were potentially >> misleading. >> > > >> > > The RMD table changes as mentioned above, and I also clarified the >> > > rows corresponding to message arrival (with message number in >> range vs >> > > message number out of range). >> > > I removed the RMD row corresponding to "Unrecoverable error on >> > > creation" as I don't think a sequence would be created at all in that >> > > case. >> > > >> > > I removed the RMD retransmitted message row as the RMD won't always >> > > know if a message is retransmitted (the first transmission might have >> > > been completely lost). The main message received row should be robust >> > > enough to deal with this, and further detail sails close to RMD/AD >> > > communication issues that are out of scope. >> > > >> > > I removed the RMD "message rollover fault" row, as an RMS is never >> > > going to send that fault to an RMD. >> > > >> > > I removed the RMD "terminate sequence" row as it was a duplicate (see >> > > 3 rows above). >> > > >> > > >> > > I hope that helps! Thanks for asking - I'm sure that you were not the >> > > only person who wanted a guide to the changes. >> > > >> > > Cheers, >> > > >> > > Matt >> > > >> > > >> > > >> > > >> > > >> > > *"Paul Cotton" <Paul.Cotton@microsoft.com>* >> > > >> > > 05/04/2006 14:55 >> > > >> > > > > To >> > > Matthew Lovett/UK/IBM@IBMGB, <ws-rx@lists.oasis-open.org> >> > > cc >> > > > > Subject >> > > RE: [ws-rx] Issue i096 >> > > >> > > >> > > >> > > > > >> > > >> > > >> > > >> > > >> > > Could you give us some explanation of the changes? In particular why >> > > are you proposing to remove two complete columns? >> > > > > >> > > Paul Cotton, Microsoft Canada >> > > 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 >> > > Tel: (613) 225-5445 Fax: (425) 936-7329_ >> > > __mailto:Paul.Cotton@microsoft.com_ >> > > >> > > >> > > >> > > >> ------------------------------------------------------------------------ >> > > >> > > *From:* Matthew Lovett [mailto:MLOVETT@uk.ibm.com] * >> > > Sent:* April 5, 2006 9:32 AM* >> > > To:* ws-rx@lists.oasis-open.org* >> > > Subject:* [ws-rx] Issue i096 >> > > > > >> > > Hi all, >> > > >> > > Here's an updated PDF for the state tables. There are quite a few >> > > updates, all highlited in blue. If this proposal is accepted by the >> > > TC, I think this leaves the tables in a reasonable state (no pun >> > > intended), so if anyone has any further ideas for changes they are >> > > probably best handled under new, specific issues. >> > > >> > > >> > > >> > > I also have the openoffice doc that produced the PDF - it may be >> > > useful for the editors if the TC accepts the proposal. >> > > >> > > >> > > >> > > Thanks, >> > > >> > > Matt >> > > >> > >> > -- >> > >> > Paul Fremantle >> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair >> > >> > http://feeds.feedburner.com/bloglines/pzf >> > paul@wso2.com >> > >> > "Oxygenating the Web Service Platform", www.wso2.com >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]