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: Re: [wsrm] MP10 question


Jacques,

Do you plan to draft the text as you proposed?
If you could do that before tomorrow, that would
be great. However, let me notify you that I have
included a proposal in the document
I have sent out yesterday, in case you are not going
to draft a text. Here is the proposal with some
amendment:

--
Add the following sentences after Line 1200 (WD1.05):
"c) If the Receiving RMP have received a message with
inconsistent group termination parameter in use
in a group, then the Receiving RMP MUST
return an InvalidMessageParameters fault. When the
Guaranteed Message Ordering is in use, the fault MUST
be returned for the first inconsistent message in order
in the group. If Guaranteed Message Ordering is not in use,
the Receiving RMP MUST return the fault to the first message
that Receiving RMP found inconsistency."

And change the following sentence numbers/characters appropriately.
(i.e., replace c) with d), and replace d) with e).)
--

Thanks,

Iwasa


----- Original Message ----- 
From: "Jacques Durand" <JDurand@us.fujitsu.com>
To: "WSRM (E-mail)" <wsrm@lists.oasis-open.org>
Sent: Tuesday, July 27, 2004 4:33 AM
Subject: [wsrm] MP10 question


> Mark Peel wrote:
> MP10:
>   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?
>
> My answer:
> Good point. Both RMP behaviors you mention above would not be desired,
> and we need to make this more explicit.
> For un-ordered groups, it may happen that the the first message(s)
> (SeqNum=0, 1,2...)
> is (are) never received, or received late, yet subsequent messages should
be
> delivered and acked. If I remember well discussions on this, the desired
> behavior
> for the Receiving RMP, would be to use the first message received, for
> adjusting the
> timeout termination conditions on Receiving RMP.
> We may want to extend (a) in 5.1.2 with a statement on this (see proposal
> below)
>
> Beside this, a late SeqNum=0 message with a different termination
parameter
> than the
> first received message for this group, would indeed reveal a discrepancy.
> But any message received for this group before SeqNum=0 must be delivered
> and acknowledged,
> even if their termination parameter happens to not match the one of
> SeqNum=0.
> Although the spec is silent on the behavior (Fault?), I believe a Fault
(and
> no delivery)
> is implied for the message received that reveals a discrepancy(here
> SeqNum=0).
>
> For improving wording of 5.1.2:
> - I propose that the last sentence of 5.2.1 be developed to list all the
> Fault cases
> related to this section.
> This could mean using a bullet list (e.g. of a bullet: "failure to satisfy
> (b) will cause
> Fault XYZ..."), and moving bullet #3 currently under (a), under this
"Fault"
> paragraph.
> - Also, enhance (a) (added last sentence):
> (a) The First message in a group (the one with
> Request/MessageId/SequenceNum/@number=0) MUST
> be used by the Sending RMP to indicate which timeout parameter is in use
for
> the group. However, the first message received for this group by the
> Receiving RMP MUST be used for indicating which termination parameter is
> associated with this group.
>
> -Jacques
>



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