Robert Sparks wrote:
So, the thing we're talking about then is not a subscription.
(You will not use the same code to service it that you would have used
to service a subcription).
Certainly the negotiation and establishment parts are different.
It is possible that the code used to determine when to send a
notification, and to process an incoming in-dialog notification, could
be the same for some event types.
That of course would only make sense if both forms were supported by a
given UA for a particular event type. And it would only be true if the
implementation *chose* to do it that way. Its clearly a local
implementation issue.
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, I think so. That is the essential simplification that might make
this attractive to some people.
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.
Well, of course it is the same UAC and UAS, so some authorization is in
common. But it is true that someone might be permitted to make a call,
but not to have access to the event data.
In that case I think it is simply a matter of not negotiating the
capability if it isn't authorized. In that case I guess it is a
simplification in that there is no way to indicate that forbidden rather
than unsupported.
Paul
RjS
On Oct 26, 2007, at 1:31 PM, Francois Audet wrote:
So, what's the duration? How do you unsubscribe?
Isn't the whole point of this proposal that it would linked to be the
duration of the dialog?
Otherwise, you would just SUBSCRIBE.
_______________________________________________
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
_______________________________________________
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
