RE: [ws-rx] Comments on Issue 66

["Yalcinalp, Umit" <umit.yalcinalp@sap.com>]

In thinking about this a bit, I am wondering one utility of the
"connected" state may be for recovery purposes or more precisely a
chance to fill the gaps in a sequence if there are some. From RMDs
perspective it is a demarcation for filling up gaps, if sequence needs
to be "restored".  

--umit


> -----Original Message-----
> From: Tom Rutt [mailto:tom@coastin.com] 
> Sent: Wednesday, Nov 30, 2005 12:52 PM
> To: Doug Davis
> Cc: ws-rx@lists.oasis-open.org
> Subject: Re: [ws-rx] Comments on Issue 66
> 
> Doug Davis wrote:
> 
> >
> > Tom,
> >   Right, it uses LastMessage to keep message numbers higher than X
> > from being delivered - which is one of the two uses I stated it 
> > appeared to be used
> > for. 
> 
> 
> Ok now the question is: does the extra state "last" matter for any 
> stakeholder in the transaction?
> 
> The sender App knows when it has sent the last message it is going to 
> send, so the "Last" state would accomplish nothing beyond keeping
> the sequence in the "connected" state (from the Hitachi State Table).
> 
> The receving RMP does not seem to benefit from this extra 
> state and its 
> required behaviour either.  
> 
> The sender cancontinue to resend non acked messages until acks are 
> received for them all.  Then It can close or terminate the sequence.
> 
> So unless someone comes up with a stakeholder use case which 
> is hurt by 
> removal of this "last" state and its associated xml syntax, I
> think we can remove it.
> 
> Tom Rutt
> non acked messages until all the acks are received.
> 
> > However, we need to look at whether the use of LastMessage 
> is appropriate
> > for this type of security hole.  If people are concerned about 
> > hijacking of sequences
> > then LastMessage is not a very good way to stop it - 
> stopping people 
> > from using
> > a msgNum higher than X but not less than X-1 is very 
> arbitrary.  The 
> > real solution
> > for this would be to use something like SecureConversation or some 
> > other security
> > mechanism.  So, while the presence of LastMessage may (or 
> may not - I 
> > need to
> > think more about it) change the state table, I don't think the new 
> > state created by the
> > presence of LastMessage is a worthwhile state - in other words, it 
> > doesn't add
> > anything of value (see my thread with Anish) and should be removed. 
> >  Just because
> > there's something in the spec that creates a new state does 
> not imply 
> > that the
> > state itself is useful.
> >
> > thanks
> > -Doug
> >
> >
> >
> > *Tom Rutt <tom@coastin.com>*
> >
> > 11/29/2005 03:28 PM
> > Please respond to
> > tom
> >
> >
> > 	
> > To
> > 	wsrx <ws-rx@lists.oasis-open.org>
> > cc
> > 	
> > Subject
> > 	[ws-rx] Comments on Issue 66
> >
> >
> >
> > 	
> >
> >
> >
> >
> >
> > Description from Issue 66 states:
> > "
> >            The LastMessage element, as part of a Sequence header
> > element, appears superfluous. It seems to serve 2 purposes:
> >        
> >            1 - force a SeqAck to be sent back from the RMD
> >
> >            2 - force the RMD to reject any messages with a higher 
> > message #
> >
> >            #1 can be done with an AckReq header.  We should avoid
> > having multiple ways to do the same thing.
> >        
> >            #2 is really only an issue if someone tries to hijack the
> > sequence - and to protect against that we should be using a
> >            real security mechanism like WS-SC/Trust, not the
> > LastMessage element.
> >  
> >            When an RMS is done with a sequence it is free to simply
> > Close or Terminate it (whether or not it has all of the Acks
> >            it wants - but normally it will wait) - having 
> an additional
> > message exchange to send a LastMessage is unnecessary
> > "
> >
> > The ws-rm spec wording implies that there is a difference 
> in behaviour
> > (as described in the Hitachi proposed state tables) between
> > the RMD in states "closed" and "lastReceived".
> >   The RMD continues to "deliver" retransmitted messages 
> with msgNo less
> > than the last messageId value, when in the last state.
> >   The RMD does not deliver any messages when in the closed state.
> >
> > This difference in behaviour is significant.  Last is used 
> for orderly
> > shutdown (with no lost messages at time of sequence terminiation).
> >
> > Tom Rutt
> > .
> >
> > -- 
> > The key issue here is
> >
> > ----------------------------------------------------
> > Tom Rutt                 email: tom@coastin.com; 
> trutt@us.fujitsu.com
> > Tel: +1 732 801 5744          Fax: +1 732 774 5133
> >
> >
> >
> 
> 
> -- 
> ----------------------------------------------------
> Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
> Tel: +1 732 801 5744          Fax: +1 732 774 5133
> 
> 
>