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

[Hadriel Kaplan <[e-mail]>]

> -----Original Message-----
> From: Scott Lawrence [mailto:[e-mail]]
> Sent: Thursday, April 08, 2010 4:51 PM
> 
> On Thu, 2010-04-08 at 15:15 -0400, Hadriel Kaplan wrote:
> > Right, but the since that would make it an "unknown validity" config,
> > and the requirements do not mandate any UA to *use* an "unknown
> > validity" config... do you see a problem?
> 
> The requirements explicitly allow the UA to use an "unknown validity"
> configuration.  

We must be having a communication problem. :)
"Allowing" the UA to do something in this context means nothing.  It means nothing because it has no teeth - the UA does not need to follow the MAY statement.  Because it does not need to, some won't.  If some won't, then the administrator cannot rely on UA's to do it, to accomplish a goal (in this case, the goal of not doing a subscription). 


> I don't think it would be appropriate to put in a MUST
> that says the UA should use any configuration data response - the data
> may be in the wrong format, corrupt, or have any other problem, so that
> would just lead to a different argument.

That's a red herring.  If the data is corrupt or wrong format, it couldn't be used even if it were of unknown validity.  And it's not like the Subscription would fix it.  There's a fundamental difference between the failure of a protocol/state-machine/parsing, and a disabled feature.

Let me put it in a different way: what the ua-config model is about is basically provisioning, right?  Would you expect a provisioning command to take effect (assuming its understood), or would you expect the device being provisioned to decide whether it takes effect or not?


> Perhaps our fundamental disagreement is whether or not having a prompt
> way to reconfigure a UA is a requirement.  When the SIP Forum chartered
> this work, it was agreed that that was requirement (and I certainly
> think it is).  I think that a configuration mechanism that does not
> allow for updates under the control of the service won't be successful.

Was it a requirement to support, or a requirement to use?


> Could we allow the Configuration Service to omit the Link?  Obviously,
> we could.  I think that would materially reduce the utility of the
> protocol and would be a bad idea.  Clearly we differ on that.

Yup, on that we agree. :)

And for the record, it's not that I don't see the intrinsic value in immediate updates - it's that the mechanism to do so can't be disabled from the get-go.  The ua-config framework is about configuration, but this particular feature is not using the framework to be enabled/disabled, when it clearly could be.

-hadriel