Francois Audet wrote:
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). What I was responding
to was a proposal (by my reading) that some new header in INVITE would
mean "start sending me NOTIFY messages."
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.
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.
/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
