Subject: [dispatch] [Fwd: Re: Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03]

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Feb 2010 15:19:04 -0500

-------- Original Message --------
Subject: 	Re: [dispatch] Preliminary version of Expert review
ofdraft-avasarala-dispatch-comm-div-notification-03
Date: 	Thu, 18 Feb 2010 16:10:07 -0600
From: 	Adam Roach <[email-masked]>
To: 	Paul Kyzivat <[email-masked]>
CC: 	Avasarala Ranjit-A20990 <[email-masked]>, John-Luc Bakker
<[email-masked]>
References: 	<[email-masked]>
<[email-masked]><[email-masked]>
<[email-masked]>
<[email-masked]>
<[email-masked]>
<[email-masked]>
<[email-masked]>
<[email-masked]>
<[email-masked]> <[email-masked]>
<[email-masked]> <[email-masked]>

On 2/18/10 15:58, Feb 18, Paul Kyzivat wrote:
>
>
> Adam Roach wrote:
>> Another way to examine this problem might be to consider the state as 
>> being composed of the list of diverted callers. You can age entries 
>> out, and reset the list when diversion is shut off. Doing this makes 
>> it much clearer what should happen for the near-simultaneous case.
>>
>> Note that this is conceptually similar to what the winfo event 
>> package template does with its "waiting" state.
>
> I'm just inferring from what Ranjit has said that they envision a 
> server that doesn't keep *any* state about diverted calls. I'm trying 
> to see if this can be so and still conform to the 3265 view of the world.
>
> Do you think its a valid approach to have state instantaneously appear 
> and disappear, and for a filter to block the delivery of the 
> transitions back to nil state?

I think that's a bit tortured, as state models go. In particular, we've
defined (and are defining) mechanisms that allow various modifications
to the way SUBSCRIBE and NOTIFY work, and they assume more persistence
than what you've described. For example, consider how your proposed
state model would interact with subnot-etags or the ongoing throttling
work. It doesn't make any sense, does it? Because we're assuming real
state behind the event package, not instantaneous events that result in
no persistent state.

Really, none of this should be surprising to anyone; it's spelled out
pretty clearly in the definition of an event package as given in RFC 3265:

    Event Package: An event package is an additional specification which
       defines a _set of state information_ to be reported by a notifier to
       a subscriber.  Event packages also define further syntax and
       semantics based on the framework defined by this document required
       to convey such state information.

If you don't want to track _state_, then this is the wrong tool. If you
want to use this tool, you need to define a state model.

/a