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

[Paolo Romano <Paolo.Romano@dis.uniroma1.it>]

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.


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

 I think an easy solution to this issue might be the following. When an
 application is layered upon ws-rm, its wsdl defined MEPs should not be modified.
 Whereas its WSDL should import the ws-rm headers description, to advertise its
 supported (ws-rm) capabilities. ws-rm processors must also define and advertise
 in a WSDL their ability to receive asynchronous fault and acknowledgment
 messages.
 I have already posted this idea some time ago, but I did not get much
 feedback... Please, let me know what you think about it.

 Best Regards

 Paolo Romano

>
> 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
> >
> >
> > You may leave a Technical Committee at any time by visiting
> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php
> >
> >
>
>
>
>
> --
> Paolo Romano
>




--
Paolo Romano