On Mar 26, 2008, at 9:01 AM, Venkatesh wrote: > Paul: > > Replies Inline..... > > On Wed, Mar 26, 2008 at 6:07 AM, Paul Kyzivat <[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".....
Ask me again to tell you that I was thirsty 10 seconds ago? Why does this help anything? thanks, -rohan > 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]>> 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
