> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > > 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.
No matter which Method gets used, there will need to be some new header(s) in INVITE to negotiate. So that's equal. > - 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 don't see how that's knowable. For one, code is obviously implementation dependent. For another, we would be changing the way in which subscribe bodies could be sent (i.e., they wouldn't, not in the subscription-creation), the handling of subscription duration, and adding a directional negotiation mechanism. Lastly, you don't *have* to support rfc3265 at all to support 3261, so the code change could be quite a bit more. > - 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. True of both cases, I presume. > 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. I'm confused by this - did you mean INFO, and just that the INVITE needs the negotiation headers (as it does for NOTIFY)? > - 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. Any current event-package could not simply be used in a NOTIFY model either, for the reason you pointed out in an earlier email: we wouldn't want the package's subscribe body to be in the Invite. And really there are some that would be illogical to do so (like reg-event). So in that sense it's a wash: any current event-package wanting to be used would need an extension to say so and how, and any future ones would need to define whether or not they support this new Invite-Notify/INFO and how. > 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. That's assuming we need to actually make this create a real Subscription. That would mean you'd be including all the concepts of Subscribe usages in an Invite-created dialog, having two usages in the same dialog, etc. Since the lifetime, relationship, context, usage, etc., between the Invite and event-notification is inexorably linked, there is no need for a real Subscription. And we already have a method that has that direct relationship to Invite: INFO. -hadriel _______________________________________________ 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
