RE: [wsrm] Proposed resolution for Rel 50

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

wsrm message