see my comments in line Sal
On Thu, 2007-10-11 at 14:31 -0500, Dean Willis wrote: > On Oct 11, 2007, at 11:55 AM, Francois Audet wrote: > > > Hi Dean, > > > > Can you tell me what is the difference between "contextually-adapted > > INFO", and a "subscription embedded in the INVITE, with the NOTIFY > > using the same dialog"? I don't see any advantage to the INFO > > approach. > > > > One might argue that the second is a means of implementing the first. > > INFO, as written, lacks contextual negotiation. You're proposing to > replace the method name with NOTIFY and use the event-package > framework for content and context expression, using a header-field in > the INVITE request to engage context negotiation. It seems to me like > that would work. There's nothing "implicit" about it, and it is no > worse for overhead than using Supported or Allow. It also has the > advantage of letting us reuse an existing registration framework, > IANA process, and specification review process under RFC 3427. Very > tidy, I think I like it. the proposal is interesting. However there should be cases where you need to send whatever information in both directions, or cases where when you send an information via Notify you need to receive back some information (e.g. the fact that you receive a 200Ok as answer to the Notify it is not enough). How do you think your proposal should work in those cases ? perhaps with 2 subscription one in each direction? > > I would argue that it would be nice to have an extension mechanism > that allows a UA to be asked "Do you support this specific > extension?" without the UA having to encode every extension it > supports in every request it sends, but that's a different issue. that is also something nice. Are you thinking a mechanism like an OPTION that instead to be general just asks for a specific extension? > > > > It seems to me we already have a mechanism for asking for asynchroous > > information with subscriptions. Why not use that? > > > > As you pointed out, the current mechanism adds a dialog overhead. It > also raises issues with event-stream correlation that can be a bit of > a challenge depending on the application's API and threading model. > Your suggested workaround for in-dialog notification relieves these > issues, so it may be better than the existing mechanism for a number > of use cases. More importantly, it is no worse than NOTIFY for those > use cases (barring the small increase in request size for context > negotiation). > > -- > Dean > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
