> -----Original Message----- > From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] > Sent: 20 October 2007 02:30 > To: Paul Kyzivat > Cc: sip > Subject: RE: [Sip] INFO > > > > > -----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. [JRE] This has got me thinking again. A few days ago there seemed to be some consensus that we were not talking about a new dialog usage within an INVITE-initiated dialog, but merely an extension of the INVITE usage, which terminates with the BYE transaction. Now this would be different from NOTIFY requests arising from REFER implicit subscriptions - these constitute a separate dialog usage, termination of which is determined by the Subscription-State header field. IMO it gets very messy if we use the same method for requests relating to the INVITE usage and to other usages. So I am coming round to thinking NOTIFY would not be a good choice.
John _______________________________________________ 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
