> -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Friday, November 21, 2008 2:14 PM > > On Nov 21, 2008, at 10:27 AM, Hadriel Kaplan wrote: > > > > You create an option-tag for the specific package. Weeding out the > > "old phones" won't be enough, because many new phones won't do your > > package anyway. Such a shotgun approach is kinda useless. > > > > But that requires the specific package be a standards-track RFC. Many > won't be.
No it doesn't, not in practice. Only in some theoretical fantasy world. We're talking about a vendor who makes a proprietary package, and doesn't want it to be used in general. You think a vendor who does that, and needs to have a way to have endpoints Register the fact they can do it in a Supported header, or needs a way to check if the far-end does it in an Options, will say "oh gee I wish I could put something in the Supported and/or Require header but the IETF won't let me"?? You guys crack me up. :) And don't get me wrong: I don't mean this in the sense that we should give up specs because people don't follow them. I just mean that the use-case you're specifically talking about is a *vendor-proprietary* use-case, so why should we go provide some standard means to help them make it more easily deployable with themselves, if the means to do so already exist in a proprietary fashion *without* interop problems with those of us who follow the specs? Because putting an unregistered option name in Supported/Require should work with the same semantic behavior registered ones do no matter who you talk to. Unless someone has gone and built a box that does lookups against IANA databases every time it gets a message with an option tag it doesn't recognize and rejects it if not. ;) All we have to do for vendor-proprietary users of INFO is make sure they interoperate with those of us who don't have them, by letting them discover we don't support them. (which is what recv-info does) We don't need to work to give them more features. -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
