OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]