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