On Oct 26, 2007, at 1:48 PM, Robert Sparks wrote:
So, the thing we're talking about then is not a subscription.
Right. That's why I called it event notification within an INVITE-
initiated dialog.
(You will not use the same code to service it that you would have
used to service a subcription).
Of course not. What it is is a negotiation mechanism for INFO. You'd
use the same code for it that you used for servicing INFO. But now,
each event-carrying message also has a naming component that tells
you what you're supposed to be doing with the event notification.
And if you accept that the fates are tightly coupled (as I think
you are asserting here), then we
_don't_ have separate usages that spring into being and disappear
at the same time. There's only
one usage - the INVITE usage.
Yes, exactly.
And forgive me for continuing to point, but are you going to
address the authorization mechanics and if not, what are the
simplifying assumptions that let us ignore them.
The authorization mechanics are obvious and simple. If you're
authorized for the INVITE dialog, you're authorized for any event
notifications offered within the INVITE transaction that instantiated
the dialog.
Or hey, if you decide the peer is unauthorized during a dialog, you
either end it (with a BYE), or just stop sending the event
notifications. If they were all that important, the other end will
eventually send a BYE, right?
--
Dean
_______________________________________________
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
