On Thu, 2010-04-08 at 15:15 -0400, Hadriel Kaplan wrote: > > > -----Original Message----- > > From: Scott Lawrence [mailto:xmlscott@xxxxxxxxx] > > Sent: Thursday, April 08, 2010 9:37 AM > > To: Hadriel Kaplan > > > > Well, one could argue that a provider could cause the returned SIP url > > for the change notice subscription to be one for which there is no > > routing (return 'Link: <sip:devnull.example.org>'). By the rules, the > > UA would periodically make a DNS request to try to find it, but would be > > allowed to use the configuration data. Silly, but allowed. > > 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. 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. > Instead of getting into an unknown-behavior state, why don't you > simply allow the HTTP response to NOT have a Link header, or define a > NULL URI to use - and then state that it means there is no > Subscription service and the UA MUST consider the HTTP-based config > valid? > > No one is going to be forced to use any of this specification. If you > > don't want the features it provides (automatic initial configuration > > with prompt updates), then don't use it. > > So we should go define another profile which is a textual copy of this > one, but changes two sentences?? Is that really good for SIP or the > SIP-Forum? > > At the risk of repeating myself, I want to make sure that one reason for > > using SUBSCRIBE/NOTIFY for the change notices is clear: there is no > > other existing standard way to address a specific User Agent. > > Right, I understand that you have no other way to do X. Fine, so > specify how to do X. Don't mandate that X be used with Y, when Y does > not depend on X to function properly, and X is not trivial. 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. 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. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf