Title: RE: [wsrm] Comments on CD 0.992
Jun:
I think I agree with all that below (except my name spelling :-)
Jacques
-----Original Message-----
From: Jun Tatemura [mailto:]
Sent: Friday, April 02, 2004 6:03 PM
To: Jacques Durand
Cc:
Subject: Re: [wsrm] Comments on CD 0.992
Jaque,
My responses on your <JD> are inline:
Jacques Durand wrote:
> [1]
> The receiver can forget previous group IDs after group state removal
> but the sender MUST NOT reuse group IDs. The spec shuold explicitly note
> about the sender side here. One engineer thought the sender could
> re-open a group.
>
> <JD> Section 2.1, as well as 4.2.1, clearly state that the GroupID is
> globally
> unique, and two groups must use two distinct GUIDs.
> Now we could stress the consequence of this, which is that a Sender
> must never reuse
> previous groupIDs.
>
Yes, I am aware of that. That's why I think the logic is complete. It is
clear to me, but
maybe because I am an insider of spec discussion. The user feedback
implies we should
stress this point in the Group Closing explanation (ll.1100-1102) for
readability.
> [2]
> It should be explicitly noted that receiving "status=end" does not mean
> "Group Closing." In (t3)(t4), the spec uses another terminology
> "complete," which also confuses readers.
>
> <JD> Line 1118-1119 (section 5.1.1) defines "complete". Now we could
> add that more explicitly to the group terminology definitions in
> 5.1.1. Will propose rewording.
>
> For the receiver side group closing, we can define two categories:
> (a) group completion: the receiver RMP received all messages from start
> to end.
> (b) group timeout: (b1) the receiver RMP observes that groupExpiryTime
> specified is over
> or (b2) the receiver RMP observes that groupMaxDuration specified is
> over.
> Once we define these at the first time, termination rules would be
> much simpler and easier to understand.
>
> <JD> Fair enough. I will propose some edits for this section with your
> intro summary.
>
> [3]
> One engineer was worried about the fact that the sender's
> groupExpiryTime and
> the receiver's groupExpiryTime are not in sync. It is in fact okay
> that the
> sender does not know the current groupExpiryTime in the receiver side.
> It is better to clearly state this.
>
> <JD> I thought Lines 1086 to 1090 in 5.1.1 stated that clearly enough.
> If you have a more explicit wording to propose, let me or Iwasa know.
>
Again, I think the logic is complete.
But the fact that group termination is asynchronous does not
necessarily mean that group termination parameters are also
asynchronous. At this point of reading, the reader can expect
the spec were somehow trying to synchronize the group termination
parameters based on some asynchronous protocol. (Actually, the term
"RM Agreement items" in 5.1.2 implies they are synchronized) A careful
reader can realize that this expectation was wrong after reading termination
rules.
My proposal of wording is replacing ll.1140-1143 with:
c) The sender MAY modify the value by sending a subsequent message
with a new value.
The sender MUST use the value from the message with the highest sequence
number
sent for the group. The receiver MUST use the value from the message
with the highest sequence
number received for the group.
d) A new value for groupMaxIdleDuration can either be increased ....
> [4]
> It is not clear that when the spec states "groupExpryTime is over" in
> the sender
> side, which groupExpiryTime is observed by the sender. Is it based on
> the last message the sender sent? Or the last message for which the
> sender
> received ack? In fact, either cases are okay for reliable messaging. But
> this ambiguity confuses readers.
>
> <JD> You mean groupMaxIdleDuration? on sender side, it should be
> counted from
> the last sending (see Termination T2). We don't always assume Acks.
> Now, groupExpiryTime is a date, so no dependency on previous events...
>
The point was about semantics of groupExpiryTime for the sender
when the sender wants to modify the value of groupExpiryTime.
If the spec says GroupExpiryTime is one of Agreement items,
the reader may think the sender should use the value on which
the receiver has agreed. Since the only agreement the sender can
observe here is ack messages from the receiver, the reader may
think the sender should use groupExpiryTime for which the sender
received an ack from the receiver.
This point is actually included in the previous point [3], and the wording
proposed has resolved this.
