Sunil:
I have been thinking about the two proposed semantics for
ExpiryTime, and I do not see them as different as I thought
initially.
I must admit yours is also the original one as
currently worded in the spec. Although I believe the current semantics adds
unnecessary checks and cases, and pretends to an "application semantics" flavor
that is no substitute to business-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 when resending a message, which
I still strongly oppose (and the current spec is on my side 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.
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?
I propose to adjust my proposals of Rel52, Rel50, Rel57 to rally
the current (yours) definition of
ExpiryTime, so that we can move on.
Jacques
