RE: T2 Clarify TimeToLive

["Burdett, David" <david.burdett@commerceone.com>]

Dan you said below ...

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

If we do this, then it is an alteration to the spec as currently the sender
is free to set TTL to whatever value they want without prior agreement.
Currently persistDuration is a value that is set by the MSH that receives
the message. If you require that persistDuration > TTL for all cases, then
it will have to be set to exceed the longest TTL of all agreements.

The other alternatives I can think of are:
1. The To Party publishes their persistDuration and the sender agrees to use
a value for TTL which is less than this
2. The To Party uses TTL to work out how long to keep message for so that
persistDuration varies from message to message, or
3. The To Party reports a warning error if TTL >= persistDuration but
processes the message anyway
4. The To Party reports a fatal error if TTL >= persistDuration and rejects
the message.

I think I prefer 1 combined with 3.

Thoughts?

David

-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Thursday, September 13, 2001 12:58 PM
To: ebxml-msg@lists.oasis-open.org
Subject: Re: T2 Clarify TimeToLive


   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.)

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>