So far the devices I've seen which do proprietary option-tags in Supported generally stick to the rfc2543 defined way of doing it with the reverse domain name concept, to avoid name collision. This is in fact how some vendors are doing negotiation of proprietary-INFO right now. (you can google to see this)
And yes I agree with you that using a package type that needs the dialog to fail if the other side doesn't do it is really a bad idea or a corner case. I believe MSCML would have been an example of one that would have made sense for it, maybe. Camera control could be another one. -hadriel > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 22, 2008 9:23 PM > To: Hadriel Kaplan; Dean Willis > Cc: SIP List > Subject: RE: [Sip] INFO Framework: Tags > > The issue here is if they hit some other proprietary usage of the same > string in an option-tag. If it is an entirely closed space they should > get away with it, but in this case they can just declare the support to > be mandatory in both entities anyway. > > In any case, where any info-packages are being deployed out into general > UE space, I hope that the vast majority of these info-packages do not > need the dialog to fail if the package is not supported. In which case > we are talking about option tag needs being very much a corner case. > > regards > > Keith > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Hadriel Kaplan > > Sent: Friday, November 21, 2008 7:40 PM > > To: Dean Willis > > Cc: SIP List > > Subject: Re: [Sip] INFO Framework: Tags > > > > > > > > > -----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 > > _______________________________________________ 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
