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

Thanks for you reply..My main concern on any replacement for the "receive"
word is to avoid a protracted discussion on the meaning of the new term -
and any obligations on an RMD destination that that might imply -  when in
practice I think the intent of the spec is straightforward and
uncontroversial. Hence my suggestion of a vague term like "process".

As you say, the word "transfer" is already used (albeit uncapitalized)
throughout the document, but it's used to mean "move a message between two
points", for example

Line 16.   This specification (WS-ReliableMessaging) describes a protocol
that allows messages to be transferred reliably between nodes
Line 82    It defines a messaging protocol to identify, track, and manage
the reliable transfer of messages between a source and a destination.
Line 165  Deliver: The act of transferring a message from the RM
Destination to the Application Destination.

The definition you suggest "Transfer: The act of taking responsibility for
a message received as part of a sequence such that it becomes eligible for
acknowledgement." looks like a definition of Accept rather than Transfer. I
would be happier with the use of Accept providing we include a definition
of it like this in 2.1. However, as I said, I'm worried it would mean we
get into a long discussion of the meaning of that definition, e.g. what we
mean by "take responsibility for " and  "becomes eligible".

Having said all that I have re-read the original and I don't see that
"Receive" is really that bad. Here's how we define it

"Receive: The act of reading a message from a network connection and
qualifying it as relevant to RM Destination functions."

Doesn't the "and qualifying it as relevant" suggest some active filtering
of the incoming message by the RMD which covers most of what we need here?
Maybe all we need to do is to adjust this definition a little.

Turning to the element/message question I agree that your reworded first
sentence "If the RM Source wishes to close the Sequence, then it sends a
CloseSequence message, to the RM Destination." is a lot clearer. If it's a
message (not a header block or some element to be included at a
user-defined place in a message payload) with its own Action IRI then it
makes sense to define it as such and not require you to look at the WSDL.
One might go further and say we should give the Action IRI explicitly
rather than provide a rule for computing it.

However this logic would also apply to all the other messages defined by
the spec. They all seem to use the same formulation - first sentence
includes the phrase " an XXX element, in the body of a message," although
subsequent sentences then refer to the XXX message. For example

262 The RM Source MUST request creation of an outbound Sequence by sending
a CreateSequence
element in the body of a message to the RM Destination which in turn
responds either with a message
containing CreateSequenceResponse or a CreateSequenceRefused fault. The RM
Source MAY
include an offer to create an inbound Sequence within the CreateSequence
message.

500 When the RM Source has completed its use of the Sequence it sends a
TerminateSequence element,
in the body of a message, to the RM Destination to indicate that the
Sequence is complete and that it will
not be sending any further messages related to the Sequence. The RM
Destination can safely reclaim any
resources associated with the Sequence upon receipt of the
TerminateSequence message.

The "element in the body" phrase also appears in the wsa:Action rules

246 When an endpoint generates a message that carries an RM protocol
element, that is defined in
section 3 below, in the body of a SOAP envelope that endpoint MUST....

So if we want to consider this it should be a separate issue, covering all
occurences of "element in the body", not just this one.

Peter Niblett


"Bob Freund-Hitachi" <bob.freund@hitachisoftware.com> wrote on 05/07/2006
22:52:28:

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