Re: [wsrm] [REL-50] {WAS Rel 44: Duplicate Elimination and Time To Live (TTL)}

[Sunil Kunisetty <sunil.kunisetty@oracle.com>]

 Alan,

 REL-44 was indeed closed and the "New Spec. Issue"  you are referring is
 REL-50.

 So I believe the contents of this mail is for REL-50 and not related to REL-44.
 Resolution for REL-44 was indeed appropriate.

 As per this proposal:
 - I agree, TTL is a misnomer and MET sounds much better. The assumption
   (b) though seem implied, should be explicitly mentioned in the spec.
 - I'm wavering on the Message Duration concept, since at this time we neither
   have any WS-RM SLA concept nor capability exchange/configuration
   message. If we do have one, may be we should reconsider it at that time.
   I always believed that  SLA stuff  is out of scope of this spec.
 - As per the un-resolved issue, sending a Fault for a pure wsdl one-way
   operation is wrong, A Fault shouldn't be sent, unless <output> or
    <output>/<fault> is specified (note that as per the wsdl schema you cannot
    specify a <fault> without an <output> definition).  May be we should use the
    word  generate an error/exception as that doesn't always imply sending the
    Fault to the initial sender in the SOAP response.

 -Sunil

Alan Weissberger wrote:

> 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