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"..... 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
