[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments on CD 0.992
I have one clarification question and some editorial comments. Jun Tatemura NEC Laboratories America ----- A clarification question: How the receiver RMP can return InvalidPollRequest fault in a Response element whereas a PollRequest message does not have MessageId? (Maybe I missed some discussion done) ---- 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. [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. 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. [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. [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. ---- 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. 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" -----
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]