On Oct 26, 2007, at 5:04 PM, Paul Kyzivat wrote:
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.
I disagree - you are, I think, pointing to potential code reuse for
dealing with the payload of a NOTIFY.
The code that is involved in dealing with the NOTIFY itself is not
going to be reusable. Most, if not _all_ of the
code for dealing with a _subscription_ will likely not be reusable.
That code _has_ to assume the mechanics
of a subscription. (A NOTIFY updates the timer for how long a
subscription lasts - that notion is gone).
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.
That would well be the normal case for most of the event packages
that are currently defined (More evidence that its probably not going
to be the case that the packages for this thing and the packages for
events are going to closely line up).
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
