Hi, I don't necessarily agree with Paul that NOTIFY is better than INFO in this case, but I DO agree with him that we should try to focus on the other issues. We can use the INTIFY method "working name" for now. Later we can then decide to choose an existing method, or come up with something which sounds a little more sexy :) Regards, Christer
________________________________ From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Mon 22/10/2007 15:37 To: Brian Stucker Cc: sip; Adam Roach; Michael Procter; Elwell,John Subject: Re: [Sip] INFO I'm clearly in the minority here, in preferring NOTIFY over INFO. (Minority of one?) I agree that it is impossible to make definitive claims that something is easy to implement when talking about some hypothetical sip stack. So I will refrain from making such a claim from now on. I also agree that the name of the method is secondary to getting the functionality right. So I am fine with leaving the decision about the method until everything else is worked out. So, I think the next question is whether there should be a single event package definition mechanism for this new approach and for the 3265 type of events, or if these should be entirely disjoint. I realize existing event package definitions won't be applicable without at least some tweaks, and not all event types are suitable for both mechanisms. But I do think there are event types that are suitable for both mechanisms (e.g. dtmf and dialog) and it would be better if we didn't require independent definitions for them in both contexts. What do others think of that? Thanks, Paul Brian Stucker wrote: > > >> -----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 _______________________________________________ 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
