RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Scott Lawrence [mailto:xmlscott@xxxxxxxxx]
> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]