Here is my prognostication: if we document current usage, that is what will be used. I'm in a foul enough mood to suggest we document curent usage to foster some semblance of interoperation, do the honorable thing and note why life sucks, and then consider our work done. I would offer that any framework we come up would be nothing more than an academic exercise. I can already hear people say we need to publish how to interwork this new framework with Cisco INFO DTMF because, golly gee, that is the only thing their deployed equipment supports. Sent from my Verizon Wireless BlackBerry
-----Original Message----- From: Dean Willis <[EMAIL PROTECTED]> Date: Tue, 24 Jun 2008 14:12:49 To:Robert Sparks <[EMAIL PROTECTED]> Cc:[email protected], "DOLLY, MARTIN C, ATTLABS" <[EMAIL PROTECTED]>,Paul Kyzivat <[EMAIL PROTECTED]>, Mary Barnes <[EMAIL PROTECTED]>,Christer Holmberg <[EMAIL PROTECTED]> Subject: Re: [Sip] INFO and what to do about it? On Jun 24, 2008, at 11:52 AM, Robert Sparks wrote: > > The bet we would be placing by putting the work into creating this > framework is that it actually takes some motivation away from using > a non-standard bare INFO to realize some new application (and that > there are new applications out there where this would be a really > good tool to have to realize them). Is this framework really > lowering a barrier to entry or relieving some other pain so that the > people who would otherwise make a new non-standard use of INFO come > use it? I'm having a really hard time seeing that. > Well, that's the whole reason we write RFCs instead of just telling people to innovate, isn't it? > If we end up on the wrong side of that bet, we've arguably made > things _worse_ taking work away from other things, creating > mechanics that have to be implemented, tested and will ultimately be > abused, and not solving the actual problem in the first place. > > So, I'll continue to look for some evidence this will actually get > used and relieves some pressure to just go use INFO in a proprietary > way and skip all this standards pain (hopefully folks here can help > me with this). > > Without it, I think the better path would be to create the registry > you describe, publish an informational document pointing out the > pitfalls of the approaches they take, and get on with other work. Don't use INFO. By the way, here's the "standard required" process for registering your non-standard INFO use by MIME-type and content- disposition. . . Don't blame us when it kills you, or you have to register a new MIME or content-disposition because somebody already signed up for the one you want to use. I kind of like that approach. Can we do the same thing with P-headers? It'd sure save us a lot of work. -- Dean _______________________________________________ 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
