Re: [wsrm] Rel 44: Duplicate Elimination and Time To Live (TTL)

["Jun Tatemura" <tatemura@ccrl.sj.nec.com>]

Paolo,
Let me state my understanding on what Alan said.

> A simple question: why do we distinguish between maximum duration (i.e. maximum
> time in the persistent storage) and ttl (i.e. maximum time before the message is
> delivered to the final application, please correct me if I am wrong)?
>  Why we do not just use one of them? I mean, if we define ttl as the maximum
> time before the message is delivered, then it will have to be persisted up to
> that time. What are the advantages of having both of them? Why should a message
> be persisted longer than ttl? The receiving rm-processor should anyway raise a
> fault.

Maximum duration means that the receiver can not (will not) persist a message any longer
than it due to some limitation in its implementation. It indicates the upper limit of TTLs based on
the receiver's capability. For example, the receiver may not want to preserve a message for 100 year.
Such requests should be rejected (or ignored). The sender and the receiver should have agreement on
the maximum duration as one of the features of the receiver's service level.

TTL (or Expiration Time), on the other hand, is specified for each message based on the
sender's business needs.

Alan's 2(a) error means that, when the expiration time of a message is larger than a threshold
(i.e., max duration + current time),  the receiver can say "hey, I can not hold your message that long."
(Alternative way is that the receiver silently ignores the TTL requested and sets a (default) TTL based
on its maximum duration)

So, a message will not be persisted longer than TTL in any case.

Regards,
Jun

> > Alan Weissberger <ajwdct@technologist.com> ha detto:
> >
> > > 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
> > >