Re: [Sip] INFO considered harmful

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

Greetings,

A lurker speaks!

I've read Jonathan's draft and have some comments.  Please be advised that
these comments are meant to be constructive although they might seem a bit
heavy handed at first reading.

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.

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.

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.

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.

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.  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.  The point is, what difference does
it make.  SIP and SIPPING can't control every use of the protocol and
shouldnt try.  To this end I would propose another radical approach to this
problem.

Limit the scope of the SIP and SIPPING groups to activities having to do
with the base protocol, e.g. new methods and headers.  Handling extensions
can fall into two buckets 1) small extensions that handle corner cases in
some signaling situations that aren't covered by the SIP spec and 2) major
extensions that either add large, application-specific sets of signaling
function or have really nothing to do with signaling.  These latter
extensions should be separated from SIP and SIPPING within IETF and handled
in different WGs.

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