Dean Willis wrote: > 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. No doubt there are scenarios when this is less than helpful though. Similarly, rules on if/when resubscription is necessary would need to be agreed, rather than leaving it to 'implementor's discretion'. Interestingly, I was thinking about a related problem recently and wondered if some sort of multi-event subscribe might help with the many-dialogs problem that some people are starting to see. Francois' approach gives a related solution in the scenario where there is a call dialog in existence between the relevant endpoints. Regards, Michael _______________________________________________ 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
