Hi, all: It appears that we are almost close to have an agreement on this topic.
The basic analysis needs to be made why people like to use INFO for so many purposes in SIP. If the WG can abstract those requirements for usages of INFO and can prepare the INFO spec to meet those requirements, there will be no need for "proprietary" usages by vendors. If the WG fails to meet the above requirements, no matter what is done now or in the future will NOT stop the usage of INFO using proprietary schemes. If the past history provide any lessons, it will be a total failure. The bottom line is this: The future INFO spec MUST meet the basic requirements for which people are tempted to sue this in the first place. Best regards, Radhika ----- Original Message ----- From: Mary Barnes Date: Tuesday, June 24, 2008 10:04 Subject: Re: [Sip] INFO and what to do about it? To: Paul Kyzivat Cc: [email protected], "DOLLY, MARTIN C, ATTLABS" , Christer Holmberg > Paul, > > The grandfathering is aa good suggestion and likely far more > pragmaticthan my optimistic approach that they'll evolve. I will > go ahead and > ping our folks and see how they feel about this. If others will > do the > same, I think we'll have some very interesting results. > > Thanks, > Mary > > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2008 9:01 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Jonathan Rosenberg; Christer Holmberg; Robert Sparks; > [email protected];DOLLY, MARTIN C, ATTLABS > Subject: Re: [Sip] INFO and what to do about it? > > 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 > lightin 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. > > I think that would be better than the current situation, and about as > good as we can expect to achieve. > > Thanks, > Paul > > Mary Barnes wrote: > > Just a couple more points of clarification on my view embedded > below > > [MB]. > > > > Mary > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 24, 2008 8:25 AM > > To: Barnes, Mary (RICH2:AR00) > > Cc: Christer Holmberg; Robert Sparks; Paul Kyzivat; > [email protected]; > > DOLLY, MARTIN C, ATTLABS > > Subject: Re: [Sip] INFO and what to do about it? > > > > > > > > Mary Barnes wrote: > >> I don't believe we could ever forbid INFO. I initially did not > think > >> we could accomplish anything around INFO, but I believe some of > the > >> work that's on the table would be useful for working towards > >> interoperabilty for the INFO usages. I would be afraid to ask > >> honestly > > > >> for the identification of all the different uses of INFO that > are out > > >> there right now. > > > > I don't think we should be afraid of this at all. > > [MB] My guess (based on what I've seen) is that a lot of vendors > would > > have around a half dozen (+- 2). Now, some of those might > overlap > > given there is some level of interop between various vendors. [/MB] > > > > There are (sometimes/often) good reasons why folks resort to > these > > solutions. Our job here at IETF is to ensure interoperability > for the > > SIP protocol. If we don't listen to our customers - the people > who > > have deployed and are actually using it - what purpose does our work > serve? > > > > [MB] My experience is that at least half the uses of INFO were > in > > place when the protocol was quite immature (i.e., well before > RFC > > 3261). And, we indeed should listen to our customers by > providing a > > flexible platform for them to do the things they need to do. > IMHO, > > it's been loud and clear in the past that they want to use INFO > and in > > > the past, docs like "Info considered harmful" weren't helpful > towards > > this end. [/MB] > > > >> Doing something is better than nothing at this point IMHO and > I'm > >> personally really tired of revisiting this issue every couple > of > >> years. AND, this would help us put a stake in the group on the > future > >> usages of INFO (whether we ever get rid of the old usages or > not), as > > >> I believe there are other SDOs defining new uses of INFO right > now to > > >> add to the mix of un-interoperability in this area. > > > > As long as SIP usage continues to rise, I suspect we will > continue to > > see more INFO usages. Just because we cannot fix what is broken > in the > > > past, doesn't mean we should let it remain broken for the future. > > > > [MB] I'm not at all disagreeing on this point. Optimistically, > I'd > > like to see the current implementations evolve to support this > new > > approach as it will improve interoperability. If the WG can > complete > > this work in a timely manner (perhaps the biggest issue given > past > > performance), then the potential for uptake for a standardized > > implementation is INFO is far higher IMHO. If we can get this > work > > chartered, then we're far more likely to get uptake by the other > SDOs > > far sooner than if we continue to dillydally. And, it's > important to > > remember that this isn't the only area where there are > > interoperability issues. And, actually, per SFSIW-1 the use of > INFO > > was not a common theme - either because it was a given or it's > not as > > big an issue as some of us are assuming - in a quick scan I only > found > > one document discussing the use of INFO. [/MB] > > > > -Jonathan R. > > > > > _______________________________________________ > 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
