Jonathan: You are right and all these messes need to be addressed, but the greatest benefit is coming from ensuring interoperability across the whole product lines when application will be using INFO.
In addition, more intelligent applications will be coming out in near future using INFO schemes, which are yet difficult to imagine. So, given the environments that we have now, we have to move forward keeping our main objectives of the long run focused - i.e, INTEROPERABILTY. Best regards, Radhika ----- Original Message ----- From: Jonathan Rosenberg Date: Monday, July 7, 2008 9:50 Subject: Re: [Sip] INFO and what to do about it? To: Robert Sparks Cc: [email protected], "DOLLY, MARTIN C, ATTLABS" , Paul Kyzivat , Mary Barnes , Christer Holmberg > inline: > > Robert Sparks wrote: > > inline > > > > On Jun 24, 2008, at 9:00 AM, Paul Kyzivat wrote: > > > >> Mary, > >> > >> My latest thought is that we should "grandfather" existing uses > of > >> INFO. We would provide a registry of them, without blessing > them or > >> standardizing their specifications. That would at least shine > some > >> light in the dark corners. > >> > >> At the same time, we would define the new INFO usage framework > (still > >> TBD) and ban *new* INFO usages that don't follow it. > > > > Well, if we don't think banning INFO as a whole would be > listened to, > > why do we think banning INFO that doesn't use this new framework > would > > be listened to? > > > > That's where I'm having difficulty with the question. I can see > the bite > > of work it would take to make the framework. > > I'm still trying to see what would actually use it if we did? > > Can somebody list the packages that we've already identified > that we > > would put out with this framework? > > There are two separate questions here. > > One is: if we put out this framework, would folks currently > building > non-standard INFO usages use it for their next new proprietary > usage. > The other is, are there existing packages (standard or > proprietary) that > we would move over to this framework? > > On the former question - I think the cost of this framework is > light > enough, and the benefit is great enough (much easier determination > of > what INFO usages are supported and will be used), that there is > little > reason for folks NOT to use it. Implementors break standards not > out of > malice, but because they find that what we have produced is not > sufficient, or too expensive to implement given the value in > brings. So > the key to success is extreme simplicity. > > On the latter question - of treatment for existing mechanisms - I > think > DTMF is at least worthy of discussion. It'd be good to get a > better > sense of whether there are some improvements that could be made > upon the > current non-standard technique that might help folks move towards > a > standard mechanism. Given the huge mess that is DTMF-in-SIP right > now, > this deserves a look. I also think we might find value in looking > at > some of the event packages as INFO frameworks - conference comes > to mind > as a good one. Packages that are almost always used in > conjunction > with a dialog could benefit from definition as an INFO framework - > it > would save implementors the cost of a second dialog for the content. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > [EMAIL PROTECTED] > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ > 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
