>How about the DATA method. :) Naaah.... sounds too much Star Trek ;)
> -----Original Message----- > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > Sent: Monday, October 22, 2007 1:10 PM > To: Paul Kyzivat; Stucker, Brian (RICH1:AR00) > Cc: sip; Adam Roach; Michael Procter; Elwell,John > Subject: RE: [Sip] INFO > > 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 _______________________________________________ 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
