[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Additional 1.05 questions/clarifications
The following readings (or their potential corrections) are unclear to me. 119-120: Synchronous messaging applications require immediate knowledge of the message status (e.g., Error) Should "Error" read "fault"? 261-262: When an RMP supports both Deliver and Respond, then it MUST be able to associate a payload obtained via Respond, with a payload previously delivered (Deliver), based on Consumer demand. What does "based on Consumer demand" mean? When the RMP supports both Deliver and Respond, it seems to me it should be able to associate Respond payloads with the Deliver payloads that evoked them whether the Consumer wants the Respond's payload or not. Does it add something meaningful, or should we strike that clause? 407-408: The messaging scope of these agreement items may vary, as messages may be associated with a group. The clause "as messages may be associated with a group" does not explain why or under what circumstances messaging scope may vary (and aren't all messages are associated with groups, even if they are singleton groups?). Should we strike this clause? 835: A Sending RMP MUST include a PollRequest element when the ReplyPattern agreement item has the value "Poll". This language suggests the Sending RMP must add a PollRequest element into any message with the RM-Reply Pattern set to Poll -- which contradicts the examples given in 6.3.1 and 6.3.2 and would leave WS-Reliability with no means of doing delayed acking. Suggested rewording: 835: A Sending RMP MUST send a message which includes a PollRequest element for a group whose ReplyPattern Agreement Item has the value "Poll" some time before the group expires. BTW, does this MUST apply even if the group does not require Guaranteed Delivery? 915: The Sending RMP MUST include the SequenceNumRange element when it specifies which messages in a group are queried for status. Since SequenceNumRange (or SequenceNumberRange: see below) has a cardinality of 0 or more rather than 1 or more, I suggest this should read 915: The Sending RMP MAY include the SequenceNumRange element to request the status of 1 or more specific messages within a group. 1286: Note: In case a message is received with an ending marker, but not all previous messages have been received, then the group remains active. No termination process is initiated yet. This note about the receiver side follows a description of sender side behavior. 1931: Note: The expiry time is calculated at the time a message is sent, but adding this duration to the time the message is sent. This unclear note follows B.6.1 and B.6.3. Should it read Note: the expiry time duration value is calculated at the time a message is sent, but the Receiving RMP should add this duration to the time it received the message. Also, I found a discrepancy between the spec and the schema: PollRequest/RefToMessageIds/SequenceNumRange in the 1.05 spec is PollRequest/RefToMessageIds/SequenceNumberRange in the 1.1 schema. While the schema rules, we may wish to alter the schema in this case, as its name is inconsistent with the request element to which it refers, i.e., Request/MessageId/SequenceNum. Finally, a question. The group establishment logic outlined in 5.1.2 strongly implies a Receiving RMP cannot acknowledge messages received for a group if it has not received the group's SequenceNum==0 message: a message after the first might have invalid group items (e.g., using groupMaxIdleDuration instead of groupExpiryTime) and would get faulted after being ack'ed. Am I reading this correctly? Cheers, Mark Peel Web Services Infrastructure Novell, Inc.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]