> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Hadriel Kaplan wrote: > >> -----Original Message----- > > Lastly, you don't *have* to support rfc3265 at all to > support 3261, so the code change could be quite a bit more. > > For somebody that doesn't support 3265, and doesn't want to, > but that does want to support these new packages within an > INVITE, this is all new implementation in any case. Sure, it > would require supporting the NOTIFY *method*, as it is used > in this new usage. But the hard work is in supporting the > packages, not the method. And that part is the same either way. >
I don't agree that the method won't be hard to support. For one thing, many people use stock SIP stacks they got from somewhere else and have no idea how to add a new method or usage of a method because they've simply never had to do so before or simply can't due to other issues. Adding methods or a new nuance to an existing method may look easy on paper, but it can be a lot harder to do in practice. Much harder than, say, putting code together to toString your registration entries into XML for regevent. It's not necessarily the same either. If we use the same method, but a different dialog usage, then you could potentially have to remember which usage created the subscription in order to send the NOTIFY or process the error responses (if you're given a chance to do so by your SIP stack) in a new way. We need to take into account some history here when we're talking about fundamental tweaks to the way NOTIFY or INFO work. The dialog-usage draft makes necessary tweaks because things were broken already, but we are not similarly forced to fool with NOTIFY in this case. Non-trivial. May be worth doing, but let's not assume it's going to be simple until we have more details. Regards, Brian _______________________________________________ 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
