Re: T2 Clarify TimeToLive

[Dan Weinreb <dlw@exceloncorp.com>]

   Date: Wed, 12 Sep 2001 15:17:08 -0400
   From: "Martin W Sachs" <mwsachs@us.ibm.com>

   While we are at it, it is not at all clear if a message that has already
   been persisted should be destroyed by the MSH when TTL has expired.  Once
   the message has been persisted (and the application notified that it is
   there), it is already in the application domain.

Yes, definitely.

   Message level time-to-live functions are useful at the message layer to
   prevent a message from circulating endlessly without being delivered (the
   IP hop count is an example of this).  

And also to allow GC of the persistent storage of message ID's being used
for duplicate detection, as I've said before.

					 TTL functions related to staleness of
   the transaction are an application matter.

I agree.

   Date: Wed, 12 Sep 2001 12:37:10 -0700
   From: "Burdett, David" <david.burdett@commerceone.com>

   It shouldn't be destroyed based on TTL. The persistDuration should be used
   instead. This is the *minimum* duration that a message should retained by a
   MSH for reliable messaging purposes.

   You might argue though that if TTL is longer the persistDuration that the
   receiving MSH should persist it until after the TTL has passed. 

If any message has a TTL longer than the persistDuration, then
duplicate detection is in big trouble.  If a duplicate of a message
manages to lurk in the network for longer than persistDuration, and
then the original message is removed from persistent storage because
persistDuration ran out, and then the lurker shows up and its TTL is
not yet reached, the application will see a duplicate.  A message with
a TTL > persistDuration is treated like any other message that
violates the CPA.

persistDuration has to be interpreted as an agreement between the two
parties that every (reliable) message will have a TTL <=
persistDuration.

								   However I
   can imagine an attack whereby someone sends messages with a TTL of, say, a
   year hence just to clog up a MSH.

(Oh, I hope we don't have to try to deal with denial-of-service issues
at this point.  They're hard to deal with, and we're pretty busy
already.)