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
