On Wed, Mar 26, 2008 at 5:52 PM, Paul Kyzivat <[EMAIL PROTECTED]> wrote:
> > > Venkatesh wrote: > > > Paul: > > > > Replies Inline..... > > > > > > On Wed, Mar 26, 2008 at 6:07 AM, Paul Kyzivat <[EMAIL PROTECTED]<mailto: > > [EMAIL PROTECTED]>> wrote: > > > > I have only been loosely following this, but the following caught my > > eye: > > > > Venkatesh wrote: > > > > > [Venkatesh]: I am not sure the draft is "defining" a completely > > new > > > role. The function being performed is that of event aggregation. > > Like I > > > pointed out, it is not doing anything that violates the RFC. I am > > not > > > sure 3265 (or dialog state draft for that matter) specifically > > calls out > > > against rejecting a request by a State Agent. The way I see it > > the State > > > Agent in the proposal is doing the following: > > > > > > 1. Accept incoming NOTIFY's per dialog state RFC. > > > 2. Respond with a non 2xx response to a NOTIFY should it be > > required to > > > do glare resolution. > > > > I don't understand how there can be anything comparable to glare in > > an > > event package. If you think there is, that seems like a red flag to > > me > > that something is amiss. > > > > A NOTIFY is sent by a server possessing state, reporting on that > > state. > > The subscriber has no business arguing about it. Its like me telling > > you > > I'm thirsty, and you responding to me that I am incorrect - that I > > may > > not be thirsty now. > > > > I gather you have a state agent that is subscribing to events from > > several sources (phones) and aggregating the results. But if you want > > to > > model it that way, then the states of the phones are what they are, > > and > > it is up to the aggregator to make a sensible composite state out of > > the > > result. It has no business telling its notifiers they are wrong. > > > > > > [Venkatesh]: Paul your argument is fine; although in your example, I am > > not saying, you are incorrect, but I am saying; "I understand you are > > thirsty, but please wait for 10 seconds and ask me again"..... > > > > But I'm not asking anything. I am *telling* you I'm thirsty, because you > asked to be told. What you are proposing seems to be another form of event > notification rate limiting, without the benefit of actually reducing the > rate. > > Paul > [Venkatesh]: Sure. My only position is that whatever is being proposed is already supported in the RFC's and we don't need any new primitives from SIP/SIPPING.
_______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
