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
> The
> "Retry-After" header in the response provides this capability....The
> argument I was trying to make was that any SIP request can be
> rejected/challenged by the recipient. The same applies to a state agent
> as well. I am not sure a state-agent is required to respond with a 200
> OK should it receive a NOTIFY that has a mal-formed payload or a 'state'
> that is not even defined in dialog-state for example? I understand that
> people have taken exception to this specific usage, but from a generic
> sense, RFC 3265 has such a capability and it is this capability that we
> were proposing to use.
>
>
>
> > 3. Expect UA's not to "terminate" subscription on receipt of the
> above
> > response as the response contains a "Retry-After" header and thus
> is not
> > a "failed" request.
> > 4. Relay NOTIFY's to other MLA appearance should a NOTIFY be
> accepted.
> >
> > What is the "new role" here?
> >
> >
> >
> > thanks,
> > -rohan
> >
> >
> > > On Thu, Mar 20, 2008 at 9:47 PM, Rohan Mahy
> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
> > > Hi Venkatesh,
> > >
> > > I have described a way to implement this feature that uses
> existing
> > > mechanisms, which is what BLISS should really be about
> (how to use
> > > existing mechanism). Nobody has (yet) provided any technical
> > > argument that my proposed method will not work. The
> barrier for
> > > implementing BFCP as I described is no worse than
> implementing STUN,
> > > which many, many vendors have implemented. Several people
> on the
> > > mailing list have pointed out technical flaws with the
> intended
> > > semantics of the PUBLISH-based approach. You have an
> opportunity to
> > > just go implement something that will work. I don't get it.
> > >
> > > thanks,
> > > -rohan
> > >
> > >
> >
> >
>
>
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
