RE: [ws-rx] Comments on Issue 66

[Doug Davis <dug@us.ibm.com>]

Umit,
  If the RMD received messages
1 and 3 then when it sends back its Acks
it will include just 1 and 3.  If
the RMS tags message #3 as the lastMessage
it will not change the Acks the RMD
sends back so I'm not sure what kind of
demarcation you're thinking of.  Could
you elaborate?
thanks
-Doug

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

11/30/2005 04:14 PM

To	<tom@coastin.com>, Doug Davis/Raleigh/IBM@IBMUS
cc	<ws-rx@lists.oasis-open.org>
Subject	RE: [ws-rx] Comments on Issue 66

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