> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > > Hadriel Kaplan wrote: > > 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 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. > > So you are assuming that we would define packages that use a common > encoding and semantics for messages, but that convey them in NOTIFY for > subscriptions and in INFO for invite-dialog usage? > > That is certainly possible. It just seems unappealing to me.
Turning the tables on you: what does the method name matter? :) For one thing, it's explicit - INFO would be for notifications tied to an Invite dialog and usage, but not integral to its usage. I.e., exactly what it meant before. It would just have a new "Event"-type header, and the Invite transaction would have carried negotiation for which events could be used - neither of which require a new method name. I guess one question is which Method is more appropriate, given the dialog-usage draft. The other question is: are we really creating an implicitly-signaled Subscription. In other words, is the Invite really like REFER in this regard? If so, then we're really saying one should be able to send a Notify with subscription-state terminated, or with an expires parameter and needing refresh with a Subscribe. Meanwhile we already have an expires mechanism for Invite sessions, and it really means the Notify is tied to some second usage other than the Invite's. What would a Notify with a subscription-state of "terminated" mean in this new mechanism? (or would that header not be included?) If we're not doing that stuff, then there is no real, distinct Subscription a la Notify, and using INFO would be clear about that. > By "lighter weight subscription model" I mean negotiating the use of the > event package within the invite dialog usage. Its still a subscription > in some sense, but isn't independently refreshed or expired. Then why use a method name that has those traits? There really is NOT a Subscription in the 3265 sense of the word, is there? -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
