Title: RE: [wsrm] Rel-113 (Message delivery/processing after fault)
inline
-----Original Message-----
From: Tom Rutt [mailto:]
Sent: Wednesday, February 11, 2004 10:48 AM
To: Jacques Durand
Cc: WSRM (E-mail)
Subject: Re: [wsrm] Rel-113 (Message delivery/processing after fault)
Jacques Durand wrote:
>
> Case 2- a message requires an Ack + Dup elim, yet the receiver only
> implements Acks.
> Should the Receiver drop the message and just send back the Fault? Why
> not deliver
> the message?
>
>
> pro: the policy could be that when one party cannot fulfill the RM
> contract,
> behavior w/r applications is same as if there was no contract at all.
> Meaning always
> delivering the received message (while sending back an RM Fault.) even
> duplicates.
>
If the message is non idempotent, there may be harm in duplicate
delivery (e.g., sending a debit transaction twice).
<JD> Yes. So this option is not good...
> My recommendation: Go along the "cons" cases above. Although Case 1
> could go either way,
> it is hard to support Case 2 falling back on a default "no RM" policy.
> The "cons" cases above would still allow for non-RM behavior, via
> configurable RMP
> "default policies", as hinted above. So the current listed proposal is
> OK, after
> proposed rewording.
Does this mean we do not deliver after fault?
<JD> Yes, Fault and Delivery are mutually exclusive, for a message.
Sorry this simple conclusion was burried in my verbose mail ... (was
unwinding the reasoning to get there).
The philosophy is that if we want to deliver a message in spite of
a fault for unsupported features, this message has to be resent
with the right RM requirements (and a different ID).
