> -----Original Message----- > From: Scott Lawrence [mailto:xmlscott@xxxxxxxxx] > Sent: Monday, April 05, 2010 11:00 AM > To: Hadriel Kaplan > > One of the things that I personally fought very hard for in this > specification was removing optional behavior and choices of any kind > whenever possible. This is purely my own personal opinion, but I think > that many IETF specs have fallen into the trap of getting consensus by > making too many protocol features optional or having alternative ways of > doing things. Simplicity is virtue, and conditional statements in > specifications are sources of interoperability problems. And I'm generally very receptive to that type of argument, as you probably know. But this isn't some minor option or slight difference. This is a *vastly* different deployment model being hard-coded to "on", and forced down people's throat as a one-size-fits-all decision. You can't even turn it off through the config framework itself, because the subscription happens before the config is "valid". > If we were to > adjust this spec to, for example, allow the configuration server to > decide whether or not the UA had to subscribe, then some providers would > decide to not bother, Well if that's the case then that tells you something about how "necessary" it was, no? ;) > and some UAs would decide that since today they > only cared about that one provider they wouldn't bother to implement (or > test) that part of the spec. Pretty soon the feature is a real crap > shoot and again SIP phones look flaky and hard to administer. I freely > admit to being something of a zealot in trying to keep the specification > simple, with as few choices for any party as possible, because that's > the best way to reach universal interoperability. There is no way to police compliance. If people decide to ignore MUST statements in RFCs, then they don't comply with the RFC. If you make it mandatory for a UA, and the UA doesn't do it, then it's not compliant. Forcing the provider to deploy additional servers and a specific architecture just to force a UA to implement a MUST statement? That's bizarre. Regardless, SIP Subscription itself has interop issues, so it's not like this will be guaranteed to interop world-wide just because it works in the first instance. Since this is from the SIP-Forum, you guys actually have an opportunity to force the UA side to implement it, and do it in a common way, by branding a mark and doing a certification program for the mark - like WiFi Alliance does - which would actually improve interoperability. (if it's backed up by real 3rd-party certification, not self-certification) -hadriel _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf