Looks like we are in agreement. Your paraphrasing of my proposal is accurate.
Let's wait for other opinions. > -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 11, 2007 12:32 > To: Audet, Francois (SC100:3055) > Cc: Christer Holmberg; IETF SIP List > Subject: Francois' counter to INFO (was Re: What are we > arguing about when we say INFO?) > > > 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. > > 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. > > > > 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
