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
