So I agree with Hadriel that we want the document to be very clear on what code
the implementors need to write but I'm not exactly seeing the confusion.
Perhaps I need to go reread the doc from that point of view.
However,I did want to comment on the use cases for this. There are many service
providers that think it is important to be able to push a new configuration to
a UA "quickly" and the definition of quickly varies widely. Imagine the case
where someone is having problems getting their fax to work and the SP wants to
change the preferred codec from 729 to 711. Now I realize you could do that by
using an SBC that forced negation to only 711 but that would reduce the
flexibility of the system. Some operators want to be able to change the config
on the UA. I have talked to some that seem fine with the idea that the UA would
poll ever 24 hours or that the end user user would need to power cycle the UA.
I have talked to others that think that is totally unacceptable and need to be
able to trigger something that causes the UA to get the new config in something
more like 30 seconds. Different folks have different ideas of how fast you need
to be able to update this however when you star
t talking about how fast people would like to roll out fix to a security of
DOS attack problem, all the service providers I have talked to start talking
about much faster times than 24 hours.
I'm sure there are some deployments where polling would be fine but there are
lots that don't find this acceptable.
On Apr 5, 2010, at 3:55 PM, Hadriel Kaplan wrote:
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
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
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
Ietf mailing list
For corporate legal information go to:
Ietf mailing list