OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[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

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

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

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?


Mark Peel
Web Services Infrastructure
Novell, Inc.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]