Dean Willis wrote:
On Oct 28, 2007, at 4:58 PM, Adam Roach wrote:
Dean Willis wrote:
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.
You misspelled "any."
No, I don't believe so. It would, for example, function quite well
with MWI (although not be terribly useful).
Which is pretty much my point. I assume you picked a useless example
because there isn't a useful one. Is there anything better? Let's check
the IANA registry.
Conference? That doesn't seem to match you assertion that "partial
notification just doesn't compute." Or are you thinking you'll be
passing full conference state around in INFO?
Dialog? No, you're in the dialog -- you know how it's going.
KPML? That uses a lot of the SUBSCRIBE mechanics to set up what triggers
notification. And if the endpoints are interested, send 2833/4733.
MWI? I agree with what you say above -- not terribly useful.
POC settings? You're in a call with the device -- it no longer matters
whether it will auto answer or whether it's going to bar you from calling.
REG? This gets heavily into the authorization questions Robert was
raising (unless you're talking to yourself, in which case it's downright
silly) -- and even if we blithely wave our hands at auth and say "send
it if you like and don't send it if you don't," what is the use case?
Why would someone do this?
Refer? Spirits? Winfo? What would those even *mean*?
We've been working on this for the past 7 years, and there's not a
single reasonable proof of concept that what you're fighting so
vigorously for has any practical application. The best example you can
come up with is one you concede is useless. Robert has raised a host of
reasonable concerns, and I've been pointing out additional sets of
problems that arise from your proposal.
We know the downsides, and they are non-trivial. To make a fair
judgment, we need to balance those against the benefits. What are they?
/a
_______________________________________________
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
