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.
I agree with dean that it is explicit. It is a "subscription" in the
broad sense, but not in the 3265 sense. A formalism for its properties
will be needed, but we haven't settled on that yet.
IMO it isn't like an implicit REFER subscription. Instead of a new
dialog usage sharing the same dialog, we end up with some added behavior
within the invite dialog usage.
I do agree that we must tread carefully here because we are creating a
new kind of thing that we didn't have before. And it could have
unintended consequences, just as turned out to be the case with multiple
dialog usages sharing a dialog.
So, what's the duration? How do you unsubscribe? How do you learn about
your permissions to subscribe to the thing (pending vs active vs
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.
These are all good questions that need to be answered.
It may indeed turn out that after all those things are considered it
will be apparent that the whole thing is a bad idea.
I expect that what people are looking for is simplicity. Namely, when an
issue such as you mention starts to have a difficult answer then the
solution is to limit applicability to avoid the problem. But if it turns
out that the simplifications exclude all interesting uses then again we
pack up and go home.
Thanks,
Paul
_______________________________________________
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
