RE: [ws-rx] NEW ISSUE: Editorial messages have to be received forthem to be examined: with new highlighting

["Bob Freund-Hitachi" <bob.freund@hitachisoftware.com>]

Peter,
Yes, I know I am being perhaps a bit pedantic here, but despite how it
reads, "Receive" in a defined term in Section 2.1.  I may have gone a
bit overboard in the "element" edits and accept your comments, however I
point out that Section 3.2 in the June 27 version of WD 15 says 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."

Looking at the WSDL (and it is clear only from the wsdl). That there is
defined a CloseSequence message.

So, that sentence above is perhaps better reworded to read:

"If the RM Source wishes to close the Sequence, then it sends a
CloseSequence message, to the RM Destination."

Can we agree on that?

As for the "receive" word:
Although the use of receive in the original text is not capitalized,
even a plain reading is inaccurate.
The specific kind of behavior that is being discussed is the transfer of
a message as the word transfer is used throughout the remainder of the
document. Perhaps transfer is the word that ought to be used to wit:

Change:(line 436 ibid) from:

"While the RM Destination MUST NOT receive any new messages for the
specified Sequence it MUST still process RM protocol messages."

To
"While the RM Destination MUST NOT transfer any new messages for the
specified Sequence it MUST still process RM protocol messages."

And insert a new definition after line 164 ibid:

Transfer: The act of taking responsibility for a message received as
part of a sequence such that it becomes eligible for acknowledgement.

Does that suit you better?
Thanks
-bob

-----Original Message-----
From: Peter Niblett [mailto:peter_niblett@uk.ibm.com] 
Sent: Wednesday, July 05, 2006 5:17 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: with new highlighting

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