[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] i0019 - a formal proposal - take 4
DougD, On 01/09/05 10:34, Doug Davis wrote: > > DougB, > I like the 1st change if others are ok with it. My only concern is > that it doesn't > explicitly say that SequenceClosed could/should be used instead of > TerminateSequence - which wouldn't allow the RMS to get the final ACK. > > What about: > > In the case where the RM Destination wishes to discontinue use of a > sequence it may 'close' the sequence itself. Please see wsrm:Final > above and the Sequence Closed fault below. Note the SequenceClosed > Fault SHOULD be used in place of the SequenceTerminated Fault, > whenever > possible, to allow the RM Source to still receive Acknowledgements. > ?? wfm > re:2nd change - I agree that its untestable but there's there's part > of me that > worries that w/o saying that the RMD can't deliver those messages on > to the app in some DA, some implementations would deliver them. It > should > be obvious but I thought being clear about it couldn't hurt. Like > with the > first change, if others are ok your suggestion then I'm ok. Not our problem to address but I agree with polling the group. > I'd like to discuss these two on the call today to see what other's think. +1 thanx, doug > re:3rd change - yes - that's a typo. > > thanks! > -DougD > > > > *Doug Bunting <Doug.Bunting@Sun.COM>* > Sent by: Doug.Bunting@Sun.COM > > 09/01/2005 11:45 AM > > > To > Doug Davis/Raleigh/IBM@IBMUS > cc > ws-rx@lists.oasis-open.org > Subject > Re: [ws-rx] i0019 - a formal proposal - take 4 > > > > > > > > > > Doug, > > A few smaller, potentially editorial questions: > > On 01/09/05 06:41, Doug Davis wrote: > ... > > > In the case where the RM Destination wishes to discontinue use of a > > sequence it may choose to 'close' the sequence itself. In cases where > > the RM Destination wishes to generate a Fault but still allow RM > >protocol > > messages (for example, AckRequested) but not allow any new application > > messages to be processed it may use the SequenceClosed Fault in > place of > >the > > SequenceTerminated fault. Since the SequenceTerminated fault may > > result in the state information about the sequence to be reclaimed, > > use of the SequenceClosed fault will allow the RM Source to still > > retrieve a final and accurate accounting of the state of the sequence. > > > > > I find the above fairly difficult to parse. The choices I see for the > RMD are to send a <SequenceAcknowledgement/> containing <Final/> or to > issue a Sequence Closed fault. The first choice is not covered above. > The second choice is covered but might be more clear without repeating > text from elsewhere. How about: > > In the case where the RM Destination wishes to discontinue use of a > sequence it may 'close' the sequence itself. Please see wsrm:Final > above and the Sequence Closed fault below. > > > When a Sequence is closed and there are messages at the RM > Destination > > > > that are waiting for lower-numbered messages to arrive (such as the > > case when InOrder and ExactlyOnce delivery assurance is being > enforced) > > > > before they can be delivered to the RM Destination's application, > the RM > > > > Destination MUST NOT deliver those messages. > > > > > The above seems untestable and invisible on the wire. It also applies > MUSTs to the RMD to AD interface which go much further than the rest of > the WS-RM specification, potentially to the detriment of the DA ("almost > perfect in-order with warnings" anyone?). A RMD implementation which > delivers all messages to the AD but clearly identifies the existence of > gaps should be allowed. I recommend deleting this paragraph. > > > The following exemplar defines the <wsrm:Closed> syntax: > > > > /wsrm:CloseSequenceResponse > > > I hope you mean <wsrm:CloseSequenceResponse> on the line above. > > thanx, > doug > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]