-----Original Message-----
From: Scott Lawrence [mailto:xmlscott(_at_)gmail(_dot_)com]
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf