Re: [Sip] INFO considered harmful

["Frank W. Miller" <fmiller@sentito.com>]

Thanks for the thoughtful reply.

Comments inline...

----- Original Message -----
From: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
To: "Frank W. Miller" <fmiller@sentito.com>
Cc: <sip@ietf.org>
Sent: Thursday, January 02, 2003 4:01 PM
Subject: Re: [Sip] INFO considered harmful


>
> Sometimes, there is a need for vendor proprietary extensions
> to such protocols. However, all vendor extensions need to live within a
> "sandbox" that limits the scope of what can be done.

I think this is really the crux of the issue for me.  Because this is a
signaling protocol and not a routing or transport protocol, the need to
provide for corner cases and extensions over time is greater.

> The problem with INFO is that it defines no such sandbox.

Absolutely correct and absolutely a potential problem for a variety of
reasons, including clobbering the intermediary servers.  But, the reality
is, application implementors need some kind of app-to-app tunneling for
stuff that isn't explictily handled.  Also a reality is that INFO has been
around for awhile and people are using it.  In lieu of something better, the
mechanism has to be there.  In a way, using INFO can actually be a good
thing because it paints a great big red "A" on the packet as soon as it show
up somewhere.  If it were in some other legal method that was being abused,
the potential for abuse might not be as easy to spot.


> Let me take this to the extreme. By your argument, TCP should allow for
> vendor-specified plug ins for congestion control. After all, why should
> IETF prevent me from using something that works well for MY application?
> Indeed, there is lots of research on different congestion control
> algorithms. TCP should allow those to be used! But, would you really
> want someone to be able to plug in a congestion control algorithm that
> basically doesn't do congestion control algorithm? I should hope not.
>

Your point is well taken, but I would refer back to my earlier statement.
This is a signaling protocol, and has different, higher-level semantic
requirements placed on it.  The need for various congestion control
algorithms (to continue your example) is mitigated by the fact that the
existing protocol covers a huge portion of the requirement space.  This is
not as clear with a signaling protocol.

> >
> > As has already been noted in this thread, there are a number of fine
> > implementations (including Dynamicsoft) in the field, many, if not all,
> > including a punt to the application of the INFO body.
>
> Frank, pointing a finger at me and saying "but your company does it!" is
> neither a compelling argument or, IMHO, a civilized way to conduct a
> discussion on the list. It is frequently the case that ones company does
> something that one does not like, because a customer asked, or a partner
> is doing it, or because of one reason or another. Does that mean that we
> should be promoting such things as IETF standards?
>

My apologies.  I should have realized that just because it might be in your
product, that would not necessarily affect your opinion in the IETF forum.
But that was not really the intent of my comment.  I was simply trying to
point out that the need for tunneling is apparent since all the major
vendors are supporting what their customers have required, nothing more.


>
> > This is very useful
> > functionality to implementors and as such it makes very little sense to
> > deprecate this method.  Another will take its place as the abused.  For
> > example, I've had discussions with people about doing extensions using
> > SUBSCRIBE/NOTIFY that had nothing whatever to do with events just
because of
> > the "political incorrectness" of INFO.
>
> Unlike INFO, SUB/NOT defines a very well-scoped and limited repetoire of
> behavior for packages. So, while someone may violate the spec and do
> something inappropriate, it would not be IETF compliant. WIth INFO, one
> can do bad things and still claim to be compliant to the specifications.
>


So, there it is.  What we really need is a substitute for INFO that works
the way implementors need but also has the appropriate scaling and safety
properties.  I think the substitute consists of two parts.

1) A method/methods that allow for some degree of application-to-application
tunneling
2) An IETF process associated with this method that allows for incorporation
of this tunneling into the mainline protocol over time

Ideally, if 1) is done right, very little syntactic change to extensions
would be necessary for 2) to happen.  The split of SIP into SIP/SIPPING was
a step down the road to 2)  What was missing from that was 1).  If there was
a a 1), the flow of new elements coming into these WGs and subsequently into
the standard might have more rigor and hopefully progress more quickly.

Thanks again,
FM

Frank W. Miller, Ph.D.
Chief Technical Officer
sentitO Networks, Inc.
fmiller@sentito.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip