Title: RE: [wsrm] Comments on CD 0.992
Jun:
responses on the group termination <JD>:
-----Original Message-----
From: Jun Tatemura [mailto:]
Sent: Friday, April 02, 2004 2:28 PM
To:
Subject: [wsrm] Comments on CD 0.992
----
Overall editorial comments:
This comment does not affect the nature of the specification
but points out readability issues.
I have some feedback from engineers inside NEC, who were confused
in interpreting the spec, especially on the group termination (5.1).
The group termination rules are introduced in order to minimize
the receiver RMP implementation's cost on data persistence.
I think the logic is correct and complete but the writing is
not user friendly. Readers are required to read the spec very
much carefully to avoid misinterpretation.
Here are some implications from the feedback
[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.
[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.
[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...
----
<JD> agree with most comments below, will propose some rewording.
Editorial comments:
3.3 (l.548)
> the receiver's RMP
must be
> the receiver RMP
4.2.1.1 (ll.701-703)
> the receiver of the message MUST make messages available to the
application layer
> only after all messages with the same groupId value and a lower
number value have
> been made available to the application.
must be
> the receiver RMP MUST NOT deliver the message until all messages with
the
> same groupId value and a lower number value have been delivered.
4.2.1.1 Table 3
> See 3.1.2 for details
There is no section such as 3.1.2
4.2.1.1 (ll.763-767)
> When an application is ....
This discussion should not be done in 4.2.1.1(4). This part should be
moved to somewhere in 3.3 or totally removed.
<JD> should be removed.
4.3 (l.846)
> notSupportedFeature
must be
> NotSupportedFeature
4.5.2 (l.1052 and Table 17)
Faults are somtimes "thrown" and sometimes "sent."
For consistent use of terminology, a fault should
be "sent."
5.1.2 (l.1133)
> termination rules t1, t2 or t3 described below
should be
> termination rules t1, t2, t3, or t5 described below
since t5 is applied even when a group persistence parameter is present.
5.1.3 (3) (ll.1021-1202)
Even in case of subcase 3.2, the state can become subcase 3.1 by
receiving missing message
before reaching states t1 or t2. The sentence could be something like
"Then the Receiver RMP MUST apply termination rules of (t1) or (t2)
or apply termination rule of (t3.1) after all message have been delivered"
<JD> Although we list t3.2 and t4.2 in termination cases, these are not causing the closing of groups. We just had them here to show howq the same event (as t3.1, t4.2) will NOT entail closing because of a different context. OK we should be more explicit here that these cases will fall back on t3.1, t4.1.
-----
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
