Sunil:
My next action will be
to revise Rel52, 57 based on this.
Some more inline
comments, though.
-----Original
Message-----
From: Sunil Kunisetty
[mailto:]
Sent: Thursday, November 13, 2003
9:06 AM
To: Jacques Durand
Cc: Iwasa;
Subject: Re: [wsrm] Proposed resolution for
Rel 50
Hi Jacques,
Jacques Durand wrote:
Sunil:
I have been thinking about
the two proposed semantics for ExpiryTime, and I do not see them as different as
I thought initially.
That was
my point all along.
-
Either assume that it was application's responsibility and leave all the times
altogether
[I
disagree with this, but stating it]
- If we are doing Expiry checks, might
as well do it when the realm of RMP ends, i.e.,
when RMP makes the message
available to the user. I hardly see any gain in doing any
checks at the time of
receiving.
[Jacques
Durand] from our implementation perspective (Fujitsu), we certainly
see a significant benefit in checking ExpiryTime at reception time,
as we don't want to process further and do duplicate checks on messages
that we know up-front will never make it to the app. (So two checks will be in
order for us.)
But there is more to
fix even if we keep previous semantics: the "processing model" we had outlined
in last f-2-f Wednesday minutes, 6.2 Rel50) does not hold anymore, w/r to Acks:
If you don't require an up-front expiration check, that means you will Ack
positively an expired message, then later send an Error for non-delivery to app
due to expiration.
I must admit yours is also
the original one as currently worded in the spec.Although
I
Yes. I'm
not proposing anything new. Just want the current semantics to
stand.
believe the current
semantics adds unnecessary checks and cases, and pretends to an
"application
Only thing
would be one additional "timestamp" stamp. This is a drop in the ocean
especially we
will have to do
many other checks for DE and trying to compute the max(ExpiryTimes)
"if"
neither of the other
parameters are available.
As per the rules on the Sender, the same
rules apply irrespective of it. For ex., we cannot
assume even otherwise that Ack means
that the Receiver will always make the Msg. available
to the User. Because, after sending an
Ack. for an out-of-order Msg., the Group may have
terminated/removed before it was every
made available. So the Sender still has to obey the
rules I mentioned in one of my previous
rules. Essentially, the rules on the Receiver for
the group termination/removal applies to
the Sender also. So I don't see any additional
complexities on the rules by saying that
ExpiryTime semantics are the current TTL semantics.
[Jacques
Durand] If we keep it as is, one more rule now for not delivering an Acked message,
is that if it expires. Agree group termination does not seem to be affected
much one way or the other.
(This was the point I was making at the
F2F.. which no one seems to caring :))
semantics" flavor that is
no substitute tobusiness-level timeout handling in the application in my view, I
can settle with this.
The inconsistencies you
still see in my proposal (your scenario case), however, I contend only occur if
you authorize the Sender to bump-up ExpiryTime whenresending a message, which I
still strongly oppose (and the current spec is on myside on this, see 3.1.4 in
V0.7). Indeed, I believe this ExpiryTime update does not have any semantic
ground, and introduces all sorts of complications, from dup elimination
to group expiration management.
I believe
I can clarify the semantics very clearly without any confusion. However as I
said in my
previous mail,
this is not a big deal for us and we can still certainly live with the fact that
ExpiryTimes
cannot
change.
[Jacques
Durand] I’d prefer to keep ExpiryTime immutable, once it is set… (so all in all, we keep as much of the current spec as
we can :)
I thought
of another discrepancy with this model, but I don't seem to recollect right
now.
The ExpiryTime as defined
currently seems to now reflect an app to app contract, and has no reason
to see its value upgraded for a given message, I believe, due to underlying
transport/RMP mishaps.
Would you agree with this
analysis?
Yes, but that will have a
bearing on RMP implementation for persistence and DE.
[Jacques
Durand] And I think this bearing is positive, but let us postpone this debate :)
I propose to
adjust my proposals of Rel52, Rel50, Rel57 to rally thecurrent (yours)
definition of ExpiryTime, so that we can move on.
