Jacques,
Some comments below.
Jacques Durand wrote:
Rel-113 (Message
delivery/processing after fault):
Current listed proposal:
"Any message which results in a fault
should have no further processing done to it.
Unexpired message which results in a fault
will not result in the delivery of that message."
Discussion:
First I think we should state
the issue in terms of Delivery: "processing" is too vague:
"Any
message which results in a fault MUST NOT be delivered. Any delivered message
MUST NOT generate
a fault." I would drop the Expiry
line, as it is a repeat of what the spec already says (see def ExpiryTime)
Second, we should address separately
the special case of unsupported features:
It is unclear whether some Faults
should actually prevent delivery or not.
Consider "NotSupportedFeature"
fault.
Case 1- a message requires an
Ack, yet the receiver does not implement this feature.
Should the Receiver drop the
message and just send back the Fault? Why not deliver
the message?
It all should depend on the mustUnderstand (mU) attribute.
If the mU=1, and the
receiver doesn't understand it, then it MUST generate a Fault
and message should
not be delivered.
If mU=0, then if the receiver understands it, then it will deliver
and send an Ack. back
and if if the receiver doesn't understand it, it MUST still deliver
the message.
cons: the Sender may not
want to deal with an unreliable party at all. If it wants
it can always resend the message
without AckRequested (might be a configurable policy for RMP).
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.)
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?
The mU attribute is on the Request element/Header and hence either
both should be
supported or Fault is generated. The spec. doesn't allow the
liberty of pick n' chose.
between various RM features sent in the same Request Header/element.
cons: the Sender may not want
to deal with an unreliable party at all. In fact, delivering
may be harmful as duplicates
may be delivered while it was not expected from Sender.
If the Sender still wants delivery,
it can always resend the message with AckRequested
but without Dup elimination.
(might be a configurable policy for RMP).
Another policy could be to never
deliver and notify application.
So either policy should be configurable
and depends on app needs.
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.
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.
We should mention that it is OK for an
RMP to follow a default policy where a message may be resent (with a
different ID) with header adjustment so
that it does not clash with unsupported RM features on the other end,
and therefore be delivered. That is the
option of removing parts of the RM contract that can't be fulfilled.
Note that it would just be a convenience
feature, as the application may always decide to do so.
I think we are trying to solve the policy negotiation problem to
some extent which is
outside the scope of out charter.
In a future release, the spec
may require that an RMP be able
to implement at least two default
policies: "do nothing and notify app", "remove the unsupported
RM faeture and resend"(can be
adjusted for each RM features).
I think it is important for
interoperability to require this.
Atleast for this release, we need to keep it simple and less ambiguous.
-Sunil
