-----Original Message-----
From: Scott Lawrence [mailto:xmlscott(_at_)gmail(_dot_)com]
Sent: Monday, April 05, 2010 11:00 AM
To: Hadriel Kaplan
On Fri, 2010-04-02 at 12:05 -0400, Hadriel Kaplan wrote:
Obviously you could make the expiration interval long, but however
long you make it will be as long as the worst-case config-change time,
in case the Subscription server failed/restarted in-between. So that
same time is also how long the polling interval could/would be if the
UA just checked the HTTP server instead.
You assume that the configuration server looses subscription state on a
restart... that would be a pretty shabby implementation, especially
given that one would expect the subscription times to be very long (if I
were going to make a suggestion, it would be at least a week).
Nope, I make no assumptions about implementation. When I say "restart",
though, I do mean full restart - including a flush of any database, drive,
memory, whatever. That would be the worst case. And my guess is that
worst-case happens more frequently than people would like to admit. So
whatever the Subscribe's expiration time is, is as long as the worst-case
new-feature-rollout time.
I think that as
large scale service providers start to roll out better features like
custom ring tones and fancy display features (which many of the current
generation of SIP phones have, and which require configuration), they'll
need similar responsiveness (or, put another way, the ones that provide
immediate gratification will be perceived to be much higher quality
those that don't).
And that's all great and good. Again, I'm not arguing it isn't a nice feature.
But it *is* a feature. It's not inherently necessary to have Subscriptions to
make a config framework work. You're adding complexity and cost - for what you
perceive to be a necessary capability. I'm arguing it's not necessary, and we
shouldn't force people to pay for something they might not want. The IETF has
been really unsuccessful at trying to do that.
-hadriel
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf