Dan: The things that you are saying primarily is this: Present implementations by different vendors. If this is what you want as you major objective, you got it.
What IETF wants is this: INTEROPERABILITY. It is the long term objective. And interoperability is in multi-vendor, multi-product environments in the same large network without being locked into a given vendor product with proprietary implement ions. Present implementations are a mess. If people want to have this, they have already got it. IETF does not need to do anything more for them. BR/Radhika ----- Original Message ----- From: Dan York Date: Monday, July 7, 2008 10:53 Subject: Re: [Sip] INFO and what to do about it? To: Jonathan Rosenberg Cc: [email protected], "DOLLY, MARTIN C, ATTLABS" , Paul Kyzivat , Mary Barnes , Christer Holmberg > > On Jul 7, 2008, at 9:50 AM, Jonathan Rosenberg wrote: > > > 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. > > DY> I completely agree with the need for a registry of existing > uses > of INFO. At least if we know what they are, we can then > understand > what gaps in existing standards may be out there and what areas > may > need more work. Compiling such a registry also may limit further > proliferation of new uses as people looking to use INFO may find > an > existing one and use it instead. (Assuming they think to look for > > this registry instead of just going ahead with doing whatever they > > want with INFO.) > > DY> I'm not sure I fully agree with "grandfathering" existing uses > of > INFO. I mean, on the one hand, there's really nothing we can do > about > them, so in that respect they *are* "grandfathered". But I think > we > should provide some guidance to new implementors about how they > should > use INFO. So compiling a registry of existing uses would be > good... > as long as there was also some way to highlight which of the uses > are > the ones "preferred" by the IETF. > > >>> 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. > > DY> I agree that the key is extreme simplicity. However, I am > rather > skeptical that we'd see much movement over to the framework from > existing implementors of non-standard INFO usages. If you are a > vendor who has a working solution out there in the field using > INFO in > some non-standard way, what is your incentive to change that > *working* > implementation? To do so requires changing software at both ends > of > the exchange... I could easily see an environment with servers and > > clients where changing software would require new software loads > in > all the endpoints, etc., which could be quite an involved project. > > Why would a vendor do that? Especially when the existing solution > > works. "If it ain't broke, don't fix it." > > DY> I believe we would see *some* vendors make the switch, but I > think > there are a whole lot of folks out there who are just implementing > > things like SIP INFO and then perhaps not even remotely staying in > > touch with what the IETF is doing. They might not ever learn a > SIP > INFO usage framework is out there and would have no reason to switch. > > DY> To a large degree, this goes back to Paul's suggestion that we > > need a registry of existing SIP INFO uses. Maybe "registry" is > the > wrong word... maybe it's a document or wiki that captures existing > > usages in some way (beyond what is captured in a few of the INFO- > related drafts). I think we need to understand how bad the > problem is > (or not) before we can fully understand how many vendors may or > may > not move. > > > 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. > > > DY> Agreed. > > Regards, > Dan > > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation [EMAIL PROTECTED] > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Build voice applications based on open standards. > Find out how at http://www.voxeo.com/free > > > > > > _______________________________________________ > 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
