Hi, I share Brian's concern regarding stateful intermediates. They may not have knowledge of the new way NOTIFY is used, and they MAY do unwanted things in certain situations. Regards, Christer
________________________________ From: Brian Stucker [mailto:[EMAIL PROTECTED] Sent: Fri 19/10/2007 18:21 To: Paul Kyzivat; Hadriel Kaplan Cc: sip; Adam Roach; Michael Procter; Elwell,John Subject: RE: [Sip] INFO 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'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. 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
