-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Scott Lawrence
Sent: Monday, April 05, 2010 3:55 PM
On Mon, 2010-04-05 at 15:09 -0400, Hadriel Kaplan wrote:
This form of optional is right up that alley. For example, if I am a
service provider who wants to not have Subscription mode, and the only
way to do it is through UA config framework itself by setting a config
field for "Subscribe-UA-Config="false" or whatever, then clearly the
UA's MUST use the config. A MAY statement does nothing.
The draft is clear that the configuration data can modify any part of
the procedures in the draft. Section 2:
The User Agent MAY obtain configuration information by any means
in addition to those specified here, and MAY use such
information in preference to any of the steps specified
below, ...
But all that statement is "clear" about is that it's NOT clear - not clear what
the UA will do, in practice/implementation. Leaving it up to the UA to decide
what to do does nothing to assure the service provider of anything.
I'm not trying to be difficult (really!) - I'm just asking: imagine I'm a
service provider. I want my users to go into a Best-Buy/Wal-Mart/whatever and
buy a SIP phone, plug it into the Internet, download some config stuff from my
Apache HTTPS servers, and work. Can I do that, without having to also deploy
SIP Subscription servers? As I read this doc, I cannot.
So if you're looking for an escape clause, you've found it, but the rest
of the sentence is important
...but MUST be capable of using these procedures alone in order
to be compliant with this specification.
Yes, I read that and was thoroughly confused. :)
I think that the wording of that particular statement is perhaps
unfortunate, but have not found a better one. In effect, what we were
trying to do is express that the UA is not required to wait until the
subscription exists to use the data, and can continue to use the data
should the subscription fail for any reason. This prevents various
failure modes and/or delays in the UA when the Configuration Service is
overloaded or otherwise unavailable. It's not an 'optional requirement'
it's a non-requirement.
But saying "the UA is not required to do Foo" is NOT the same as saying "the UA
is required to not do Foo". In effect, any and all UA's in the Universe can
meet the former, but only some can meet the latter.
What I mean is, with this language, ALL UA's automatically comply with the RFC,
but only *some* will actually use their config without waiting for a
subscription.
-hadriel
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf