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? 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
