[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]