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

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

Gil:

Actually, your initial goal as stated in your proposal:

(a)
" [In order] to allow the RM Destination to determine if it has received
all of the messages in a Sequence,..."

Is not quite the same as:

(b)
> All we want is for the receiver
> to have the ability to determine if this scenario occurred or if it
didn't

The difference between these, is that in (b) you do not care at all
about receiving a TS/CS or not (in case not, the scenario just did not
occur...), while in order to achieve (a) you absolutely need a TS+LM or
a CS+LM, otherwise you can NOT determine if the messages you received
form a complete sequence. Now we know that this last goal (a) is not
always achievable due to loss of CS/TS. But we know it is desirable that
the protocol does its best to ensure it.  Which is why Stefan's question
is legitimate.

Let's assume (a).

My take on this, is:
- an implementation should not be required to do this extra effort of
resending CS or TS (concede it may not be clear in my previous mail).
- in case an implementation decides to support this extra effort
(controlled by an external agreement, like details of traffic message
resending), it is sufficient to do resending of CS, not of TS. 
- In all cases, and RMD implementation never needs to keep sequence
state after it got the TS.

Not sure where the "overkill" is :-)

Jacques

-----Original Message-----
From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com] 
Sent: Friday, November 10, 2006 3:36 PM
To: Durand, Jacques R.; Stefan Batres; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] PR Issue 22: concrete proposal

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>>
>