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: NEW ISSUE: Editorial messages have to be received for them to beexamined: with new highlighting


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 and surrounded by “*”

 

“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.”

 

Continue with a similar pattern through the remainder of the document…



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