Hi, >>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. > >One area that would need defining very carefully is the >question of subscription usage lifetimes. Tying them to the >lifetime of the invite usage that caused them sounds quite >tidy, and would prevent a flurry of NOTIFY/state=terminated >messages straight after a BYE. [Christer] Maybe these notifications could be sent in the BYE? And/or, maybe we could define a "dialog" value for subscription usage lifetime? I haven't thought about this proposal in detail yet, but we would also need to take the the dialog-reuse spec (which proposes NOT to mix dialog usages) into consideration. But, if we somehow could bind the subscription lifetime to the dialog lifetime I think that at least some of the issues in that spec would be solved. Regards, Christer _______________________________________________ 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
