RE: [ws-rx] PR Issue 22: concrete proposal

["Gilbert Pilz" <Gilbert.Pilz@bea.com>]

This is a giant overkill. Consider the following scenario:

1.) RMS and RMD exchange CS/CSR

2.) RMS sends a number of messages. Very few, if any, are lost.

3.) RMD acks the messages.

4.) RMS re-sends any messages that aren't acked; RMD eventually gets them
and acks them.

5.) RMS and RMD exchange TS/TSR.

I would argue that this scenario will apply to an overwhelming majority of
the WS-RM Sequences that are ever created. All we want is for the receiver
to have the ability to determine if this scenario occurred or if it didn't.
It's a very simple idea. If some of the messages never get through
(including CS or TS) that falls into the "something went wrong with the
Sequence" bucket.

- gp

> -----Original Message-----
> From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com] 
> Sent: Thursday, November 09, 2006 3:29 PM
> To: Stefan Batres; Gilbert Pilz; ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] PR Issue 22: concrete proposal
> 
> Stefan:
> In the light of today's discussion, and looking at this from 
> an "agreement" perspective, where the requirement for an RMD 
> to notify its party if it missed any message in a sequence is 
> conditioned by an [out-of-scope] agreement that would be 
> known from both parties:
> 
> - if there is such an agreement, then I would assume the RMS 
> must ensure the RMD got its LM (and if it failed to do so, 
> should notify, etc.) But this agreement could mean for RMS to 
> do LM in CloseSequence and retry as much as needed, until 
> getting the CSR, instead of focusing on TS. That seems more 
> appropriate because the time between a CloseSeq and a TS is 
> precisely intended for both parties to get in sync.
> 
> - It does not have to mandate more from TS/TSR, which would 
> be more demanding on implementations: if RMD sent its TSR, it 
> should be free to reclaim resources immediately, regardless 
> if RMS got it. RMS may try to resend TS with no success but 
> there is no harm: TS/TSR are just resource optimization 
> features as before, once LM has been secured by CloseSequence 
> exchanges.
> 
> -Jacques
> 
> -----Original Message-----
> From: Stefan Batres [mailto:stefanba@microsoft.com]
> Sent: Thursday, November 09, 2006 1:00 PM
> To: Gilbert Pilz; ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] PR Issue 22: concrete proposal
> 
> Gil,
> 
> This seems sane too me. I do have an issue that is not 
> directly related to PR0022 but seems somewhat related to how 
> we address it. With the spec as-is and with your proposed 
> changes we don't have a quick resource reclamation mechanism 
> like we did in the submitted spec. For example:
> 
> I am an RMS.
> I send one of these TS with LM.
> Should I retry if I don't get a response? Probably yes.
> 
> You are an RMD.
> You get my TS with LM.
> You send a TSR.
> Since the TSR might get lost, and because I might retry the 
> TS, you should be ready to respond to my TS retry.
> How long do you remember the sequence in case I retry?
> In the submitted spec, if you got the TS you could 
> immediately forget about the sequence and never respond 
> again. This worked because we put the LM in a Sequence header.
> 
> Thanks
> 
> --Stefan
> 
> 
> -----Original Message-----
> From: Gilbert Pilz [mailto:gpilz@bea.com]
> Sent: Thursday, October 26, 2006 12:49 PM
> To: ws-rx@lists.oasis-open.org
> Subject: [ws-rx] PR Issue 22: concrete proposal
> 
> Attached is a proposal for PR i022 in the form of a diff 
> against CD-04.
> The main points are:
> 
> 1.) wsrm:TerminateSequence has been expanded to include a 
> mandatory LastMsgNumber element the value of which is, 
> surprisingly enough, the number of the last message in the Sequence.
> 
> 2.) Sending wsrm:TerminateSequence is now mandatory; 
> basically the whole thing won't hold together unless the RMS 
> is required to send a wsrm:TerminateSequence.
> 
>  <<wsrm-1.1-spec-pr-i022.pdf>>
>

smime.p7s