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] NEW ISSUE: Editorial messages have to be received forthem to be examined:


Doug,
It may be that accept should be "Accept" and defined.
The prior text said that the message should not be received, and I think
that a plain reading of received would or might indicate some way of
blocking the message prior to it getting to the stack.  I think that
what is really meant is that the message is not a candidate for
potential acknowledgement.  Perhaps discard related wording might fit it
initial capped and its definition placed in the glossary.

BTW I noticed that the glossary definition of Send is inconsistent with
my usage in the newly submitted state tables (sigh) I guess the Sends
should be normalized to Transmits.  I ought to revise it once again.

On the rollover state underspecified, It seems to be true that issue 111
may have been incompletely incorporated into WD15 since the proposal,
modulo wording discussed on the call, was to add language to the
rollover discussion that describes that upon rollover a sequence is
closed.
There are two other places in the spec that I have found so far that
indicates that closure is optional prior to termination.  I am sure this
will be discussed further since mandating closure in one special case of
sequence termination inducing events whilst the others are optional
seems a bit inconsistent to me.

I don't think (yet) that a new state is required but may be if the text
changes to permit messages to be accepted to a closed sequence.  As I
read it, once the Sequence is closed then no further messages may be
accepted.  The only benefit to closing a sequence rather than
terminating it is to preserve state for the response to an
AcksRequested.  I have a bit of an issue with the language "new message"
as distinct from any message.  If the RMS had seen accepted it before
(thus making the message old) then it does not matter if it is accepted
again.

Thanks
-bob



-----Original Message-----
From: Doug.Bunting@Sun.COM [mailto:Doug.Bunting@Sun.COM] 
Sent: Monday, June 26, 2006 3:57 PM
To: Bob Freund-Hitachi
Cc: [WS-RX]
Subject: Re: [ws-rx] NEW ISSUE: Editorial messages have to be received
for them to be examined:

Bob,

"Accept" probably needs a definition tied with our new "discard" term.  
Does "accept" mean exactly the opposite of "discard"?  Either define it 
or use "not discard" and similar wording.

Separately, in your "[NEW ISSUE] Rollover underspecified, state of 
sequence is unclear" thread, you seem to argue for a new Sequence state 
distinct from[1] non-existent (RMD unaware), active (RMD aware and 
accepting), closed (RMD aware but not accepting), and terminated (RMD 
unaware, has this been folded back into non-existent?).  That is, a new 
state in which only the missing messages in a gap-filled Sequence are 
accepted.  The text below does not allow for such a state.  Do I 
understand correctly?

thanx,
    doug

[1] my apologies for all incorrect names, I haven't grokked the latest 
state tables yet

On 26/06/06 11:44, Bob Freund-Hitachi wrote:
>
> In WD 15 Section 302 "Closing a Sequence" it states starting on line
428:
>
>  
>
> "If the RM Source wishes to close the Sequence, then it sends a 
> CloseSequence element, in the body of
>
> a message, to the RM Destination. This message indicates that the RM 
> Destination MUST NOT receive
>
> any new messages for the specified Sequence, other than those already 
> received at the time the
>
> CloseSequence element is interpreted by the RM Destination. Upon 
> receipt of this message, or
>
> subsequent to the RM Destination closing the Sequence of its own 
> volition, the RM Destination MUST
>
> include a final SequenceAcknowledgement (within which the RM 
> Destination MUST include the Final
>
> element) header block on any messages associated with the Sequence 
> destined to the RM Source,
>
> including the CloseSequenceResponse message or on any Sequence fault 
> transmitted to the RM Source.
>
> While the RM Destination MUST NOT receive any new messages for the 
> specified Sequence it MUST still
>
> process RM protocol messages. For example, it MUST respond to 
> AckRequested, TerminateSequence
>
> as well as CloseSequence messages. Note, subsequent CloseSequence 
> messages have no effect on the
>
> state of the Sequence.
>
>  
>
> In the case where the RM Destination wishes to discontinue use of a 
> Sequence it is RECOMMENDED
>
> that it close the Sequence. Please see Final and the SequenceClosed 
> fault. Whenever possible the
>
> SequenceClosed fault SHOULD be used in place of the SequenceTerminated

> fault, whenever
>
> possible, to allow the RM Source to still receive Acknowledgements.
>
> "
>
>  
>
> All messages that reach the RM Destination are received, if they were 
> not then this language would be unnecessary.
>
>  
>
> I suggest that we use the word "accept" in these cases as in the 
> proposal below in addition to a few editorial nits:
>
> changes are highlighted in yellow
>
>  
>
> "If the RM Source wishes to close the Sequence, then it sends a 
> CloseSequence element, in the body of
>
> a message, to the RM Destination. This element indicates that the RM 
> Destination MUST NOT accept
>
> any new messages for the specified Sequence, other than those already 
> accepted at the time the
>
> CloseSequence element is interpreted by the RM Destination. Upon 
> receipt of this element, or
>
> subsequent to the RM Destination closing the Sequence of its own 
> volition, the RM Destination MUST
>
> include a final SequenceAcknowledgement (within which the RM 
> Destination MUST include the Final
>
> element) header block on any messages associated with the Sequence 
> destined to the RM Source,
>
> including the CloseSequenceResponse element or on any Sequence fault 
> transmitted to the RM Source.
>
> While the RM Destination MUST NOT accept any new messages for the 
> specified Sequence it MUST still
>
> process messages containing RM protocol elements. For example, it MUST

> respond to AckRequested, TerminateSequence
>
> as well as CloseSequence elements. Note, subsequent CloseSequence 
> elements have no effect on the
>
> state of the Sequence.
>
>  
>
> In the case where the RM Destination wishes to discontinue use of a 
> Sequence it is RECOMMENDED
>
> that it close the Sequence. Please see Final and the SequenceClosed 
> fault. Whenever possible the
>
> SequenceClosed fault SHOULD be used in place of the SequenceTerminated

> fault, whenever
>
> possible, to allow the RM Source to still process Acknowledgements."
>


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