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.
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.
(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.
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.
I propose to adjust my proposals of Rel52, Rel50, Rel57
to rally thecurrent (yours) definition
of ExpiryTime, so that we can move on.