Re: [ws-rx] NEW ISSUE: Editorial messages have to be received for them tobe examined: with new highlighting

[Peter Niblett <peter_niblett@uk.ibm.com>]

Bob

I have some concerns with these proposed changes.

Firstly most of the changes are about replacing *message* by *element*. I
assume that this is to match the wording of the first sentence. However
a) I think that term "CloseSequence message" reads easier that
"CloseSequence element" and "RM protocol messages" reads easier than
"messages containing RM protocol elements".
b) The rest of the spec refers to "CreateSequence message",
"TerminateSequence message" etc. So changing CloseSequence would make it
inconsistent with the rest of the spec.
c) Referring to element in this way could be interpreted to mean that any
message containing a CloseSequence element anywhere in its body has to be
accepted as a CloseSequence message. I don't think that this is the
intention of the spec.

I understand that an endpoint has no control over the messages that are
sent to it, and that it can't tell what a message is until it has
"received" it, however we use the term "accept" elsewhere in a different
way (Offer/Accept) and the word "accept" in this context suggests that the
message moves into some kind of "accepted" state. I think a more neutral
term such as "process" would be better. The "process" word is already used
.. "it MUST still process RM protocol messages" and I see you actually use
it in place of the fourth occurrence of receive "to allow the RM Source to
still *process* Acknowledgements"

Finally I think that the second occurence of receive, i.e. " other than
those already received at the time the CloseSequence element is
interpreted" reads better if left as "receive".


Peter Niblett

"Bob Freund-Hitachi" <bob.freund@hitachisoftware.com> wrote on 26/06/2006
20:52:43:

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