Hi, >>Man, I stopped looking for a few seconds, and we are still talking about INFO???? >> >>For the record, I don't care that much what we do. I'd say in order of >>preference: >> (1) SUB/NOTIFY-as-is-and-leave-us-alone-we-are-too-busy-and-who-cares-anyway s >> (2) NOTIFY-with-SUBSCRIBE-squished-into-INVITE >> (3) INFO+negoatiation_mechanism >> >>And for why (2) before (3), it's probably because I don't understand >>Adam's point that this is the worst possible idea even (worst that >>repurposing ACK). >> > >If by (2) you're talking about a SUBSCRIBE-initiated >subscription usage in the same dialog as an INVITE usage, >it's not nearly as bad. (It's still bad; c.f. the pain with >REFER and [as a separate issue] the difficulty managing >multiple usages in a dialog).
The idea is that you have only ONE SINGLE usage - the invite usage. Within that usage you then have something similar to "subscriptions" (if people get confused by that wording, then let's use something else). Ie you are NOT using INVITE in order to establish a separate subscription usage - ONLY to establish an invite usage (which then contains something similar to subscriptions). >What I was responding to was a proposal (by my reading) that some new header in INVITE would >mean "start sending me NOTIFY messages." Yes. >If that didn't make you shudder, you missed something. Go >back and re-read it. > >For the bystanders: one problem is that you're changing what >INVITE means, and you're changing what NOTIFY means -- and in >a very non-trivial fashion. Eric has some good, practical >examples in this thread about why this creates nearly >untenable complexity for user agents. I don't think you are changing what INVITE means: You use INVITE to establish an invite usage - as you have done since the day SIP was born. What you ARE doing is enhancing the invite usage, by adding something the possibility to send something similar to events within it. >We've also known for many years now that one method with two >effects is bad -- it is very difficult to account for the >various failure and half-failure modes that result if one of >the effects doesn't go as planned. The idea is that nothing changes. You would only have a single invite usage, and everything within shares the fate of that usage. Regards, Christer _______________________________________________ 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
