Re: 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