Rel 44: Duplicate Elimination and Time To Live (TTL)

["Alan Weissberger" <ajwdct@technologist.com>]

All

The Issues List indicates that Rel 44 Duplicate Elimination and Time to Live (TTL)is CLOSED, but on last week's conference call I believe we decided to pursue as follows:

New Spec issue: What should receiver do if it receives an Expired message?
Related issue: better define semantics of TTL
------------------------------------------------------------------------------------

1.  Time To Live

I always wondered how the receiver knows that the message it just received has TTL expired?  

I was told by a colleague that TTL is not the duration of the message (as one would expect from its meaning in networking), but it's the actual time that the message expires.  If that is the case than it should be renamed "message expiration time."  (It's like the "Expires" entity of an HTTP header)

We make the following assumptions on the sender and receiver that can handle TTL (or Expiration Time):

(a) They have agreed on the Maximum Duration for expiration (the receiver does not want to keep messages forever).  This could be done as part of a subscription/SLA or as a capability exchange/configuration message sequence at start-up time (i.e. prior to sending WS data messages).

Suggest we include this Maximum Duration value into the list of configurable parameters.

(b) Their clocks are properly synchronized to avoid pre-mature or late expiry of the message (i.e. the time difference between sender and receiver clocke should be less than some agreed upon threshold)
------------------------------------------------------------------------------------

2.  What should receiver do if it receives an expired message

(a) First, if the receiver detects the Message Expiration time (now known as TTL) is greater than the agreed upon Maximum Duration, then the message should be discarded and a Fault Message generated with Cause Code= Coding error in Message Expiration field.  This is detected by the receiver when Message Expiration (of received message) - Current Time > Max duration.

(b) Second, if the receiver detects Message Expiration time is later than current time, then message should be discarded and Fault Message generated with Cause Code= Message arrived after Expiration time.

Unresolved Issue:  If the message exchange pattern is  1-way only, then should we still allow fault messages to be sent in opposite direction?  In other words, permit 1 way SOAP message transfer, but require 2-way control/ error messaging at WS-RM layer (above SOAP).


Alan Weissberger
NEC Labs America
2013 Acacia Ct
Santa Clara, CA 95050-3482
1 408 863 6042 voice
1 408 863 6099 fax