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: RE: [ws-rx] PR007: concrete proposal


This looks good. My only comment is that I think the use of responding party/receiving party throughout should be sender/receiver instead.

-----Original Message-----
From: Gilbert Pilz [mailto:gpilz@bea.com]
Sent: Wednesday, January 10, 2007 3:49 PM
To: Matthew Lovett
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] PR007: concrete proposal

I think you are right about removing the "Closing" state from the RMD table and moving straight to the "Closed" state. The spec says that the RMD has to include a SeqAck+Final header when it sends a CloseSequence message. This means it can't accept any more Sequence Traffic messages because that would invalidate this header. This means that, effectively, the RMD's state moves from "Created" to "Closed" when the RMD sends a CloseSequence message.

The rest sounds right to me as well. Attached is another draft of the proposal with a "Terminating" state added to the RMD table.

- gp

p.s. I would like to commend those that worked so hard to add the state tables to the spec. Without them I doubt we would be thinking things through to this level of detail . . .

> -----Original Message-----
> From: Matthew Lovett [mailto:MLOVETT@uk.ibm.com]
> Sent: Wednesday, January 10, 2007 5:22 AM
> To: Gilbert Pilz
> Cc: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] PR007: concrete proposal
>
> Hi all,
>
> The text changes look ok to me, though I do wonder what the RMD is
> supposed to do with the TerminateSequenceResponse. If we assume that
> the RMD is going to maintain enough state to recognise the Seq Id in
> the TSR, then we do need to add a new column "Terminating" into the
> RMD state table.
>
> I think that the "Closing" column doesn't need to be added into the
> RMD state table. The only time we move into this state is the
> <CloseSequence
> autonomously> row, and I think we should move immediately
> into "Closed"
> state. That removes most of the blanks in the table. I think that
> there are 3 others, CloseSequenceResponse [msg] / Created state
> TerminateSequenceResponse [msg] / Created state
> TerminateSequenceResponse [msg] / Closed state
>
> I think it is correct to leave those blank, as the introduction to the
> table says:
> "A blank cell indicates that the behaviour is not described in this
> specification and does not indicate normal protocol operation.
> Implementations MAY generate a Sequence Terminated fault (see section
> 4.2) in these circumstances."
> which seems to apply here.
>
> I guess one purpose of the Closing column is to have a state where it
> is clear that we can resend close messages, but I think that can be
> expressed by making the <CloseSequence
> autonomously> / Closed state send a new CloseSequence message
> instead of the current N/A.
>
> Back to the possible "Terminating" state - I think it's unlikely that
> an RMD that has decided to terminate a sequence would ever want to
> retransmit the terminate, or do any work with the
> TerminateSequenceResponse, so adding a new column seems like a bit of
> a pain. However, if we do it then:
> "TerminateSequence autonomously" / Created and Closed states
> -> move to [Terminating] state
>
> Within the Terminating state:
> All inbound messages (except for the TSR) would generate
> UnknownSequenceFaults, an inbound TSR would move to [none] state. The
> only internal event that makes sense is "TerminateSequence
> autonomously", which would result in a new TerminateSequence message,
> and all other internal events are N/A.
>
> How does that sound?
>
> Matt
>
>
> "Gilbert Pilz" <gpilz@bea.com> wrote on 10/01/2007 00:58:15:
>
> > Attached is a new version of the proposal for PR007. As
> Doug suggested
> > I have updated the state tables to reflect the fact that
> the RMD can
> > send CloseSequence and TerminateSequence messages. I'm not really
> > happy with my changes to the state tables though. I added a
> "Closing"
> > state to the RMD table, but many of the cells are not
> filled in. Also
> > I am debating on whether or not to add a "Terminating" state to the
> > RMD table. I don't think it really needs it, but I would like other
> > peoples opinions.
> >
> > - gp
> >
> > p.s. Outside of Doug's comment, I haven't seen any
> discussion of this
> > proposal on the mailing list. If you wait until the concall
> to read it
> > and then have a lot of objections I will personally hunt
> you down and
> > . . . well I'm not sure what I'll do but it won't be pretty!
> >
>
>


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