I've been reading this thread and so far, it seems that folks are
recommending one or more of the following approaches:
1) do nothing
2) document what's out there in some ways
(as informational or a new class of WCP RFCs,
worst-current-practices)
3) define new framework for info
(as part of the standard track)
Eric's info draft-02 intended to obsolete 2976 and still showing
intended status as standard track.
The intended audience is both implementers and users (end-users,
enterprise, operators).
--- implementers
I believe implementers are faced with a basic problem when deciding what
to implement: what other vendor products is my implementation supposed
to interoperate with? Is that other implementation in my customer's
hands. If so, what is that other vendor implementing for this
pseudo-info functionality. Correct me if I'm wrong but I think this
often leads to the INFO path for all the uses Eric documented. Even if
an implementer argues that KPML should be used to pass digits on the
signaling path, if the customer has a box that has INFO for that, they
will likely do info and argue later because there is often little room
for a user/operator to ask for an upgrade of the already deployed box
for a new entrant.
=> implementers' vote count and what would they choose?
Likely:
1 (because they don't care, those hacks get driven by
customers to interwork with existing gears or they build products in
between UAs...)
2 (because they'd like to avoid defining yet a new hack
and would rather code an INFO mechanism to address the maximum number of
implementations out there)
Other Opinions?
--- users
While some architects push for pure standard solutions, the reality is
often darker. Users have often a service or application goal and if it
takes an INFO to get the job done given a box in the field, so be it.
They will try to ask for better solutions in upcoming releases (some of
which never address the INFO hacks which is the problem).
=> users' opinion count and what would they choose?
Likely:
2 (because they'd like to point to a document and say: I
use this as my UA on my PC/network, and it supports INFO as defined by
that doc section X.Y).
Other Opinions?
2 seems at a first sight to be the best worst thing to do. But doing 2
is a slippery slope for the IETF though: is INFO worth it? What about
the call diversion headers we can't seem to get rid of in favor of the
their alternative standard-track mechanisms?
It would be good to see a more detailed draft documenting the uses of
INFO (with actual snippets) and some rational numbers indicating how
many implementers (& releases of their code) support those, and how many
users have those. That could be beneficial to just discuss what to do,
if anything.
Jean-Francois.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Robert Sparks
> Sent: Tuesday, June 24, 2008 10:52 AM
> To: Paul Kyzivat
> Cc: [email protected]; DOLLY, MARTIN C, ATTLABS; Mary Barnes; Christer
> Holmberg
> Subject: Re: [Sip] INFO and what to do about it?
>
> 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
