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