On Oct 26, 2007, at 9:45 AM, Robert Sparks wrote:
On Oct 26, 2007, at 9:36 AM, Dean Willis wrote:
On Oct 25, 2007, at 4:59 PM, Robert Sparks wrote:
And there we go... not even 20 minutes.
So, you are right for INFO as we have historically known it.
This new gorgon that Dean is proposing is not like that INFO.
It's something that's carrying state based on (effectively) an
implicit subscription (or something very much like a
subscription, but without any of the control infrastructure) in
the INVITE.
I'd like to point out, it is not an implicit subscription. It's
explicit. The event package usage was negotiated in the INVITE
transaction. So even if we followed the current dialog usage model
and terminated the dialog, that would arguably be a reasonable
thing to do. The failure-to-understand a body means that there was
a failure in the offer/answer exchange for the event package, and
somebody needs to know about it.
It's just as implicit as the subscription to the refer event
package is when you accept a REFER, and it's going to suffer from
exactly the same problems we have there.
So, what's the duration?
Until the dialog ends.
How do you unsubscribe?
BYE.
How do you learn about your permissions to subscribe to the thing
(pending vs active vs denied)?
You don't. Either stuff shows up, or it doesn't. Or, put another way,
the other end TOLD you that you were authorized when it made the
offer. There is no "pending", no "denied".
I'm not really asking for that design right now, just pointing out
these as examples of the questions that the _implicit_ subscription
you're talking about would have to address - and remember the
hairier ones after that, like how you cause a full-state notify to
happen if you get out of sync in some partial scheme.
BYE. INVITE.
Seriously, this stuff only makes sense for fairly atomic events.
Partial notification just doesn't compute. That's why it would be
silly to say it works for all event packages.
--
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
