Comments: <scott></scott> inline...
> -----Original Message-----
> From: Alan Weissberger [mailto:]
> Sent: Wednesday, July 09, 2003 2:31 PM
> To: Jun Tatemura; ;
>
> Subject: Re: [wsrm] Rel 44: Duplicate Elimination and Time To
> Live (TTL)
>
>
> Paolo
>
> Clarification on why we need a Message Expiration time and an
> upper bound (=absolute maximum) Message Duration time:
>
> 1. We should redefine ttl as the latest (actual) time, that
> the message can be delivered to the WS-RM client. [Let's
> rename it "message expiration time," instead of TTL]. This
> time includes message delivery/ transit time + retransmission
> time (if necessary)+ message persist (=store and hold) time
> at the WS-RM receive entity (if necessary).
<scott>
I agree with Alan that TTL does not accurately reflect what the parameter
represents. MET does seem better.
</scott>
>
> The WS-RM receive entity may have to be persist (=store) the
> received message up to the message expiration time if the
> WS-RM client is busy/ unavailable/used local (=inter-layer)
> flow control.
>
> 2. I proposed that "Maximum duration" should be a
> configuration/ subscription parameter that is urgently needed
> so we have an upper bound on Message Expiration time. This
> would prevent very long hold/persist and/or message delivery times.
>
<scott>
While "max duration" does seem like a very reasonable piece of info for the
sender to have, I think it falls in the bucket of other QOS parameters that
we have discussed and is something negotiated out-of-band and the spec
should probably not specify the semantics of out-of-band parameters.
On the other hand, I think the spec should address the semantics of WSRM
parameters that the receiver cannot honor, including an MET that the
receiver "knows" it can never support.
</scott>
> Message Expiration time= current time (at the sender) +
> maximum duration of this message (which is less than the
> absolute maximum duration time parameter set at subscription/
> configuration time).
>
> 3. More importantly, if the WS-RM receive entity receives a
> message that has expired, it should be discarded.
<scott>
Agreed - receiving an expired messages should ALWAYS be discarded, however,
I do not think this should be silent but must raise a fault.
As someone pointed out, we need to define the message flow for faults. The
following logic I think will work for any binding:
IF transport is req/reply AND the SOAP MEP is req/reply THEN
add WSRM fault headers to SOAP reply
ELSE
create new one-way SOAP message (with empty body) and send it to the
"replyTo" address.
ENDIF
BTW, I think the above is the same logic for a WSRM ACK.
</scott>
>
> alan
> ----- Original Message -----
> From: "Jun Tatemura" <>
> Date: Wed, 9 Jul 2003 10:47:13 -0700
> To: <>, <>
> Subject: Re: [wsrm] Rel 44: Duplicate Elimination and Time
> To Live (TTL)
>
> > 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 <> 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
> > > > > 1 408 863 6042 voice
> > > > > 1 408 863 6099 fax
>
>
>
>
>
> You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.ph
p
