Subject: Re: [Sip] INFO and what to do about it?

From: Eric Burger <[email-masked]>
Date: Fri, 4 Jul 2008 13:40:02 -0400

I agree with Paul here.  We register (on request) existing "wild"  
usages (Cisco INFO, Sonus INFO, MSML, Nortel INFO, Others?) and  
existing negotiated usages (MSCML). We offer the "right" way of doing  
UUI, WITH A DIFFERENT METHOD, BECAUSE AS DEMONSTRATED, ANY OTHER USE  
OF INFO WILL NOT BE INTEROPERABLE WITH OLD INFO, and do registrations  
for that method.

Capiche?

On Jun 24, 2008, at 2:03 PM, Paul Kyzivat wrote:

> Robert,
>
> I will agree that the scenario you pose is a possibility. And if it  
> seems probable then we should do nothing.
>
> The carrot we could offer would be the registry. New usages would  
> get into the registry, but new usages of INFO without the framework  
> would not be eligible for the registry.
>
> Whether that is perceived as a carrot is an open question. It may be  
> that most existing usages that haven't come through ietf don't  
> *wish* to be public. If not, then there is nothing we can do.
>
> 	Paul
>
> 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?
>>>
>>>
>>> I think that would be better than the current situation, and about  
>>> as good as we can expect to achieve.
>> I'm still not convinced it makes it better. One outcome I can see  
>> from following this path is two years from now finding ourselves  
>> with no actual packages using the framework and  a set of _new_  
>> INFO based applications in the field that _don't_ use the framework.
>> Will we continue to put those in this proposed registry above? Or  
>> do we just have another set of practices that we have to treat the  
>> current non-standardized INFO uses with now?
>> 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.
>> 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.
>> I'll also, of course, accept a community decision to just do this  
>> work and take the risk of losing the bet and help make sure we  
>> build the best framework possible if that's where we really want to  
>> go. I just hope somebody can convince me we're not trading off  
>> other work we could be benefiting from more to find ourselves in  
>> effectively the same position two years from now.
>> RjS
>>>
>>>
>>>   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-masked]] Sent:  
>>>> Tuesday, June 24, 2008 8:25 AM
>>>> To: Barnes, Mary (RICH2:AR00)
>>>> Cc: Christer Holmberg; Robert Sparks; Paul Kyzivat; [email-masked];  
>>>> 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-masked] for questions on current sip
> Use [email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Jul 2008 09:50:14 -0400

inline:

Robert Sparks wrote:
>> 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.
> 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-masked]
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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Mon, 07 Jul 2008 10:14:26 -0400

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-masked], "DOLLY, MARTIN C, ATTLABS" , Paul Kyzivat , Mary Barnes , Christer Holmberg 

> (still

---

From: Dan York <[email-masked]>
Date: Mon, 7 Jul 2008 10:45:45 -0400

>>> 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.

> 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?
>
> 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-masked]
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

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Mon, 07 Jul 2008 11:13:01 -0400

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Jul 2008 12:17:25 -0400

inline:

Dan York wrote:
> 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.)
> 
> 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.
> 
>>> why do we think banning INFO that doesn't use this new framework 
>>> would be listened to?
>> The other is, are there existing packages (standard or proprietary) 
>> that we would move over to this framework?
>>
>> 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.
> 
> 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?  

Not much. I think we're talking about new stuff. I am making the 
assumption that we're not 'done' - we'll see continuing needs for new 
signaling data transfer, both standards-based and proprietary.

-Jonathan R.

---

From: Dan York <[email-masked]>
Date: Mon, 7 Jul 2008 12:29:44 -0400

On Jul 7, 2008, at 11:13 AM, Roy, Radhika R Dr CTR USA USAMC wrote:

> 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.
>

DY> 100% agreed!  I *don't* want the mess we have today.

DY> But by the same token, there's not much in the short-term that we  
as the IETF can do about the current mess unless we are prepared to do  
the dramatic step of killing off INFO (and then somehow mystically  
getting the vendors to go along with it and actually drop INFO  
support, which I can't see even remotely happening).  INFO is out  
there... people are using it as a simple messaging channel and are  
doing all sorts of things with it.  Simplicity is useful.

DY> I agree with all those who have said the best we can do is to  
provide a "recommended" way to use INFO with the carrot being that if  
you do it that way you will have interoperability.  I agree with the  
idea that we should have a prominent registry that shows registrations  
that use the IETF-recommended way of using INFO.  Only those usages  
that use the recommended way should be in that registry.

DY> However, I do think there is also value in perhaps a *separate*  
registry that documents existing non-standard and non-interoperable  
usages of INFO for a couple of reasons.  First, we gain a better  
understanding of the problem space and exactly how people are using  
INFO.  Perhaps out of that we'll learn where other protocols could be  
improved so that people would not choose using INFO. Perhaps we'll see  
gaps that could benefit from standardization.

DY> Second, we may prevent further proliferation/creation of new INFO  
uses.  Someone looking to use INFO in their application might find the  
first registry (standard, interoperable) and not find the particular  
usage they are after there. With the second registry (non-standard,  
non-interoperable) they might find a usage there and use that one.   
Yes, we now have a vendor using a non-standard, non-interoperable  
usage of INFO, but at least they have not gone off and created yet  
another non-standard, non-interoperable INFO usage.  If we can limit  
the proliferation of new INFO uses, then there may be more of a chance  
of helping move some of those usages over to standardized,  
interoperable uses over time.

DY> Now, to encourage adoption of the standard, interoperable uses, I  
would suggest that the web page for this second registry be titled  
something like "NON-STANDARD, NON-INTEROPERABLE USES OF SIP INFO" with  
some explanatory text at the top that explains why it would be better  
to use the standard, interoperable INFO uses and provides a pointer  
over to that registry.

Regards,
Dan

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Mon, 07 Jul 2008 13:15:35 -0400

Dan:

I would not see any dis-agreement with your approaches. Let us see what is actually proposed in the incoming INFO proposal drafts: Interim solutions (may be non-Interoperable) and Long-Term Interoperable solutions.

BR/Radhika