> -----Original Message----- > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > Sent: Friday, October 19, 2007 4:10 PM > To: Paul Kyzivat; Stucker, Brian (RICH1:AR00) > Cc: sip; Adam Roach; Michael Procter; Elwell,John > Subject: RE: [Sip] INFO > > Hi, > > One potential issue: the stateful intermediate receives a > NOTIFY without any previous SUBSCRIBE. Is there a chance it > would act on this, e.g. by sending a 4xx response, or are we > sure it would always simply forward the NOTIFY and assume the > endpoint will handle it?
It depends upon how much state this stateful intermediate is keeping. If it's transaction stateful, then no, it shouldn't care (as it won't have remembered any of the previous transactions once their response was sent back anyway). However, it is entirely possible that, without performing anything untoward (i.e. not a B2BUA) that a proxy may remember whether or not a SUBSCRIBE had previously been sent for a particular NOTIFY and kill the NOTIFY as a security measure thinking that someone's up to no good trying to spoof a subscription. Yes, this would generally break implicit subscriptions, but they've generally pretty ill-advised because of their security profile. For example, I may send regevent NOTIFYs to endpoints telling them they've been forcefully deregistered looking for a gullible UA that will bump itself off the network. I'm just concerned that by using a method from 3265, with new semantics, that it could confuse boxes that aren't aware of what's going on. If it were a different method, either INFO+ or something new, then I'd be less concerned because the whole thing would just look like a regular transaction to the untrained implementation. > > Regards, > > Christer > > > > ________________________________ > > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Fri 19/10/2007 18:52 > To: Brian Stucker > Cc: sip; Adam Roach; Michael Procter; Elwell,John > Subject: Re: [Sip] INFO > > > > > > Brian Stucker wrote: > > If we're going to change the way that error messages are > handled that > > are returned for NOTIFY messages isn't it going to be a bit > > complicated to determine at the transaction layer if the NOTIFY was > > negotiated via INVITE or via SUBSCRIBE? > > > > I mean, the endpoints may know what's going on, but boxes in the > > middle might not. > > I don't see any reason why *proxy* middle boxes need to know > anything about this. B2BUAs will need to know, but then they > will know. > > > I'm a bit concerned that by tweaking 3265 in this way we're > going to > > move more complexity into all subscription processing > whether it's a > > usage within a dialog, a separate dialog or this new thing. > > It would only affect those that support it. > > And I don't think it will be a big deal, but then this is > just speculation at this point, since no details have been > worked out. Its always possible that it would turn into a mess. > > Paul > > > Regards, > > Brian > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > >> Sent: Friday, October 19, 2007 10:55 AM > >> To: Hadriel Kaplan > >> Cc: Elwell, John; sip; Michael Procter; Adam Roach; Stucker, Brian > >> (RICH1:AR00) > >> Subject: Re: [Sip] INFO > >> > >> > >> > >> Hadriel Kaplan wrote: > >>> Which is one of the reasons I think it should be INFO. > >> Using it would only be an update to rfc2976, right? > >>> -hadriel > >> I don't think the distinction is significant. Either way > it should be > >> designed to be backward compatible. And neither way will require > >> actually changing those other documents. > >> > >> Using NOTIFY: > >> > >> - will need some new header(s) in INVITE and responses to > negotiate > >> this > >> new capability within the invite dialog usage. > >> > >> - once that is done it will have established some new > rules for using > >> NOTIFY in that context. This will not be used unless negotiated, > >> so there aren't any backward compatibility issues. > >> > >> - for those that *do* support this, the same code should ideally be > >> able to use either this technique or real > subscriptions, with only > >> minor tweaks. > >> > >> - I would expect that any event packages defined in the future that > >> could meaningfully be used in this way would be > designed from the > >> ground up to support both styles. > >> > >> Using INFO: > >> > >> - I don't think it will be sufficient to just add headers to > >> NOTIFY itself. IMO there still needs to be negotiation of > >> the particular usages of NOTIFY. So there still need to be > >> new header(s) in invite and responses. > >> > >> - once the negotiation is done there will need to be some new > >> header(s) to provide added context for the INFO. > >> > >> - any usage that currently has an event package would have > >> to be modified to be used with INFO. > >> > >> Bottom line - I think a "lighter weight" subscription mechanism > >> serves all the same needs that an enhanced INFO does, is > no harder to > >> implement, and has other benefits. > >> > >> Thanks, > >> Paul > >> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > >>>> Sent: Friday, October 19, 2007 7:48 AM > >>>> To: Elwell, John > >>>> Cc: sip; Michael Procter; Adam Roach; Brian Stucker > >>>> Subject: Re: [Sip] INFO > >>>> > >>>> Yes, my thinking has been that this would be a matter of > >> negotiating > >>>> the use of NOTIFY *within* the invite-dialog-usage. Of > course that > >>>> isn't legal today - this would be an extension to both > >> 3261 and 3265. > >>>> Paul > >>>> > >>>> Elwell, John wrote: > >>>>> Michael, > >>>>> > >>>>> Yes, I guess some of the postings on this thread have > >> hinted that it > >>>>> would be the same dialog usage. I suppose if the > >> subscriptions are > >>>>> deemed to terminate at the time of the BYE transaction, then it > >>>>> would indeed by the same dialog usage. So it would appear to be > >>>>> within the letter of the dialogusage draft. However, one or two > >>>>> postings have suggested different. > >>>>> > >>>>> John > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Michael Procter [mailto:[EMAIL PROTECTED] > >>>>>> Sent: 19 October 2007 08:48 > >>>>>> To: Elwell, John; Adam Roach; Paul Kyzivat > >>>>>> Cc: sip; Brian Stucker > >>>>>> Subject: RE: [Sip] INFO > >>>>>> > >>>>>> John, > >>>>>> > >>>>>> My impression of the discussion so far is that using > NOTIFY (or > >>>>>> INTIFY as Christer suggests) in this way would not > >> constitute a new > >>>>>> dialog-usage. A new usage would imply periodic > >> resubscription and > >>>>>> specific termination, whereas sending INTIFY within the > >> context of > >>>>>> the INVITE-usage means that the lifetime issues can be ignored: > >>>>>> terminate the call, and INTIFY no longer has a context. > >>>>>> > >>>>>> This neatly avoids violating the letter of the > >> dialogusage draft, > >>>>>> but you could probably argue that creating sub-usages of the > >>>>>> INVITE-usage isn't necessarily in keeping with the > >> spirit of the draft... > >>>>>> Regards, > >>>>>> > >>>>>> Michael > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Elwell, John [mailto:[EMAIL PROTECTED] > >>>>>>> Sent: 19 October 2007 07:41 > >>>>>>> To: Adam Roach; Paul Kyzivat > >>>>>>> Cc: sip; Brian Stucker > >>>>>>> Subject: RE: [Sip] INFO > >>>>>>> > >>>>>>> Adam, > >>>>>>> > >>>>>>> Now that you have reminded us of the dialogusage draft, > >> perhaps it > >>>>>>> would be appropriate to remind people of the > following from the > >>>>>>> abstract: > >>>>>>> "This memo argues that multiple dialog usages should be > >> avoided. > >>>>>>> It discusses alternatives to their use and clarifies > essential > >>>>>>> behavior for elements that cannot currently avoid them." > >>>>>>> In other words, while it will only be an > Informational RFC, it > >>>>>>> seems to deprecate introduction of further dialog > >> reuses. So if we > >>>>>>> were to go with NOTIFY, would this be a new dialog > >> usage, and if > >>>>>>> so, > >>>>>> do we really > >>>>>>> want to go ahead with something in contradiction to the > >> sentiment > >>>>>>> of that recently-approved draft? > >>>>>>> > >>>>>>> John > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Adam Roach [mailto:[EMAIL PROTECTED] > >>>>>>>> Sent: 19 October 2007 01:05 > >>>>>>>> To: Paul Kyzivat > >>>>>>>> Cc: sip; Brian Stucker > >>>>>>>> Subject: Re: [Sip] INFO > >>>>>>>> > >>>>>>>> Paul Kyzivat wrote: > >>>>>>>>> I mostly agree with Adam. The place where I take exception > >>>>>>>> is INFO. It > >>>>>>>>> is my impression that INFO was designed for use with > >> INVITE, and > >>>>>>> so > >>>>>>>>> should be considered to be part of an invite-dialog-usage. > >>>>>>>> And Robert > >>>>>>>>> specified it that way in the dialogusage draft. > >>>>>>>> You're correct. I had forgotten about that, and the > dialogusage > >>>>>>> draft > >>>>>>>> does make it clear: INFO is part of the INVITE usage. RFC > >>>>>>>> 2976 predates > >>>>>>>> the current terminology, but a quick re-read does show > >> that it's > >>>>>>>> pretty clearly appropriate only for INVITE usages. > >>>>>>>> > >>>>>>>> /a > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > > > > > _______________________________________________ > 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
