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