> -----Original Message----- > From: Michael Procter [mailto:[EMAIL PROTECTED] > Sent: Monday, October 22, 2007 3:01 AM > To: Stucker, Brian (RICH1:AR00); Paul Kyzivat; Hadriel Kaplan > Cc: Elwell, John; sip; Adam Roach > Subject: RE: [Sip] INFO > > > > -----Original Message----- > > From: Brian Stucker [mailto:[EMAIL PROTECTED] > > Sent: 22 October 2007 08:48 > > To: Paul Kyzivat; Hadriel Kaplan > > Cc: Elwell, John; sip; Michael Procter; Adam Roach > > Subject: RE: [Sip] INFO > > > > > -----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. > > On a similar note, I suspect that adding a header (Event?) to > INFO would be simpler than subtracting a mandatory header > (Subscription-State) from NOTIFY, purely in terms of the > support for each in 3rd party stacks. > > Of course, I am making a whole bunch of assumptions here that > aren't necessarily true. So maybe this decision can be > postponed until a few more details are ironed out. >
In this case, I think it's a pretty safe assumption. Subtracting mandatory headers from a method is not a great idea because now you've added a new path in the code where the header is semi-mandatory and the information to determine when it is mandatory, and when it is not, is not present in the message itself (so the stack may have to ask the application what's going on when it's trying to verify that the message is minimally correct which may not be possible/desirable). If I get an INFO with an event header in it, and I'm not looking for an event header in an INFO, then I'm no worse off than I am today, right? Besides, the event header isn't useful to the lower protocol layers. It's only useful to the application itself, whereas the subscription-state header is often handled by another chunk of code whose sole responsibility is to maintain subscriptions and is neither part of the stack, nor the application, but used by both. 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
