[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] INFO considered harmful
Frank W. Miller wrote:
Greetings,
I would take issue with the basic premise of the draft, which is that the
SIP and SIPPING groups need to have control over every bit that passes
through a SIP message. It is not possible for the standard to anticpate
every situation that people might want to use the protocol. It's
interesting how many times I've heard WG members say, "thats not what I
intended it for". The beauty of SIP is that its basic framework and
semantic level endear it to so many different signaling situations. The use
of INFO to supplement the corners of specific applications is a very
important part of that versatility.
It is the job of the IETF to define protocols that interoperate, that
scale well, that have good security, that don't congest the internet,
and so on. 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. Specifically, that
sandbox has to draw the line around issues of scale, security, and
congestion control, which affect *other* networks and other vendors.
IETF protocols are used on networks where other things live too.
The problem with INFO is that it defines no such sandbox. It allows
anything, and can be used in ways which will cause problems when those
messages flow through other vendors equipment or run on other networks.
The clearest example of that is the rate. A record-routing proxy in some
other domain might get a flood of INFO messages because some app in
someone elses server thought INFO was a good way to tunnel voice.
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.
JR cites three specific problems with INFO:
Lack of interoperability: This is not a problem. Since the INFO contents
are explicitly outside the standard, this must be assumed by the
implementor. If they persist with INFO to implement some signaling
situtations, there are likely other good reasons for doing so.
You have not properly interpreted my draft. THe interoperability failure
is that there is know what to know the intent of the INFO method. There
is no way to signal that this is the "frank's extension usage" as
opposed to anyone elses.
Inappropriateness: As I've already stated, I do not feel that the SIP and
SIPPING working groups should (let alone can) realistically expect that they
can determine how and when the protocol will be applied in applications at
this late date.
Please see my above comments on this. I believe that this is a
fundamental issue about the role of IETF in protocols.
Incorrectness: Jonathan is eluding to the possiblity of errors being present
in the protocol extensions. Well, this is not the SIP and SIPPING groups
problem. These extensions are outside the scope of the standard. If the
purveyors of the extension design the error, they're responsible for it, not
the SIP and SIPPING groups.
Except where those extensions impact other servers, vendors or service
providers. And they can.
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?
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.
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
jdrosen@dynamicsoft.com FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.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