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