Subject: [Sip] INFO considered harmful

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Dec 2002 15:12:03 -0500

Folks,

For some time, I've been complaining about the continued abuse of the 
INFO method for things that should be done other ways (frequently, not 
using sip at all). I've written up a summary of the problems and a 
proposed path forward. Specifically, I'd like to obsolete INFO and 
replace it with a spec that is approved ONLY for SIP-T.

Until the I-D appears, you can pick up a version at:

http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt
http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Dec 2002 13:21:16 +0200

Hi,

From a SIP point of view your draft is basically talking about putting
restrictions on what kind of message body types to use in INFO, since the
SIP stack really doesn't care about what the application does with the
data sent in the INFO.

Now, does this mean that we also need to restrict what kind of message
body types we allow in INVITE, re-INVITE and UPDATE? I know the stack can
ignore message body types it doesn't support, but if people start sending
their DTMF tones etc in THESE messages I think we still have the same
interop/wrong-use-of problem as we currently have with INFO, don't we?

Just some thoughts...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Dean Willis <[email-masked]>
Date: Sat, 28 Dec 2002 00:29:03 -0600

> http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html

Jonathan and I have had "extended discussions" on this. I'm more 
inclined to think that INFO needs specifications for specific usages, 
much as we use "events packages" for SIP Events (SUBSCRIBE, NOTIFY). In 
my own completely non-original way, I call these "INFO Packages".

I think that the SIP-T usage of INFO is a perfect example of an INFO 
package. However, I think it is NOT the only reasonable use for INFO. 
Unsolicited in-dialog "stuff" is pretty darned useful. All we really 
need is for the usages to be differentiable, negotiable, and 
well-documented. Admittedly, INFO doesn't have any of those three 
characteristics right now, but I think we can probably fix it without 
breaking too much existing stuff.

Anybody else have a third opinion?

--
Dean
Not Speaking From The Chair.

---

From: "Adam Roach" <[email-masked]>
Date: Sat, 28 Dec 2002 01:26:17 -0600

From: "Dean Willis" <[email-masked]>

> Anybody else have a third opinion?

Not exactly a third opinion, but here goes: I agree 100% that something must
be done about the current state of INFO. So far, with the one well-known
exception, INFO has just served as a way that people can throw random crap
in the body of a meaningless message so that their implementation has no
chance of interoperating with any other, but can still claim 100% compliance
with IETF proposed standard documents. (The embarassing thing is: they're
not lying.)

I'm not so set on which of the two actions (packages, or restriction to
SIP-T) is correct. However, I find a couple of arguments that Jonathan makes
in the draft extremely compelling:

1. The INFO spec does not actually define any semantics. It
   only says "this acts like a BYE, except that it doesn't tear
   the session down".

2. Any new feature that INFO enables could be defined
   by adding a new method; and, the existence of the INFO
   spec does not provide any ease over doing so.

I'll add a third: despite INFO being an RFC for more than two years, there
have been no additional internet-drafts that suggest alternate legitimate
uses for this method. If it were useful enough to warrant saving, certainly
at least one additional use would have been identified by now.

These arguments would seem to indicate the path of deprecating INFO except
for its only currently approved purpose: ISUP transfer. I can probably be
swayed, but haven't heard any counter-arguments yet.

/a

---

From: "Adam Roach" <[email-masked]>
Date: Sat, 28 Dec 2002 13:50:54 -0600

From: "Christer Holmberg" <[email-masked]>

> body types we allow in INVITE, re-INVITE and UPDATE?

Not really. INVITE means something: it means "I'm trying to set up a
session, and here's a description of that session." The first half ("I'm
trying to set up a session") has specific semantics associated with it. The
second half ("here's a description of that session") tells you exactly what
goes in the body.

INFO just says "Here's a framed chunk of data."

There is no valid comparison between the two.

/a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 28 Dec 2002 20:24:39 -0500

inline.

Dean Willis wrote:
> well-documented.

The point I was making in the draft was - why bother? INFO by itself 
provides nothing. If you want differentiable, negotiable and 
well-documented things, define them as new methods. What does INFO give 
you beyond that?

 From the stool then? ;)

-Jonathan R.

---

From: "Cullen Jennings" <[email-masked]>
Date: Sat, 28 Dec 2002 21:11:31 -0800

Proposal 3 might result in moving the problem from INFO to the MESSAGE
message.

Cullen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
> Sent: Thursday, December 26, 2002 12:12 PM
> To: [email-masked]
> Subject: [Sip] INFO considered harmful
>
>
> Folks,
>

---

From: "Adam Roach" <[email-masked]>
Date: Sun, 29 Dec 2002 00:19:25 -0600

From: "Cullen Jennings" <[email-masked]>

> Proposal 3 might result in moving the problem from INFO to the MESSAGE

Yes, but that's an obvious and intentional abuse of the system, not a
well-intentioned attempt at something "standard." Certain parties may
actually be hellbent on being incompatible, and there's nothing we can do to
fix their attitude. For the only slightly misguided, though, we could make
it at least somewhat obvious what behavior is going to lead to interop
problems.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 29 Dec 2002 20:13:52 +0200

Hi,

> There is no valid comparison between the two.

I agree that the semantics of the commands are different. However, one IS
allowed to include any kind of message body in the INVITE request, to provide
whatever "extra information" about the session (text, HTML, whatever...), so
someone could argue that whatever stuff they put into the INVITE does provide
"extra information" about the session...

And, since it IS allowed to send re-INVITE, or UPDATE, without actually
updating the session description (the SDP message body) someone could include
that whatever stuff also in those messages...

I am not saying that anyone is doing that TODAY, though...

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Adam Roach" <[email-masked]>
Date: Sun, 29 Dec 2002 12:44:36 -0600

> that whatever stuff also in those messages...

Ah -- I see what you're saying. The proposal was floated to deprecate INFO
except for its currently defined use (ISUP transfer) -- so, you're arguing
that we should deprecate INVITE except for its currently defined uses
(setting up and modifying sessions), and deprecate UPDATE except for its
currently defined use (modifying sessions), right?

That's... interesting.

/a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Dec 2002 11:34:59 -0500

inline.

> "extra information" about the session...

There is a huge difference that you are ignorning.

The semantics of INVITE are well defined. SIP-guidelines says bodies 
can't change that basic semantic. Same with UPDATE.

INFO has no defined semantic. Thus, it is not currently a violation of 
the spec (and indeed, seemingly encouraged by it) to place all kinds of 
stuff in it. THis is why we HAVE seen abuse of INFO, but not INVITE or 
UPDATE.

-Jonathan R.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Dec 2002 09:30:38 -0800 (PST)

> stuff in it. THis is why we HAVE seen abuse of INFO, but not INVITE or 

  So... s/INFO/X-SIPPING and be done with it?

	Mike

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 30 Dec 2002 13:15:46 -0600

Christer said:
> I agree that the semantics of the commands are different. 
> However, one IS allowed to include any kind of message body 
> in the INVITE request, to provide whatever "extra 
> information" about the session (text, HTML, whatever...), so 
> someone could argue that whatever stuff they put into the 
> INVITE does provide "extra information" about the session...
> 
> And, since it IS allowed to send re-INVITE, or UPDATE, 
> without actually updating the session description (the SDP 
> message body) someone could include that whatever stuff also 
> in those messages...

That's actually quite interesting. One can get the same functionality as
INFO using UPDATE methods. For example, SIP-T could encode the mid-session
ISUP and send it using UPDATE.

So, what is the semantic differentiation?

I propose that we've been operating under a logic system where "UPDATE
affects SIP state and INFO doesn't". It might be that this exposes a fallacy
(which one might call "telephone centric" thinking) in our logic. There are
really two different "sessions" in a typical SIP exchange: 1) The SIP-level
session, or "dialog", framed in INVITE and BYE or SUBSCRIBE and BYE, and 2)
the negotiated session, expressed in SDP, which may or may not exist.

Since there may or may not be a negotiated session, and since SIP works just
fine either way, is it reasonable to divide SIP mid-dialog semantics into
"things that we think might affect the negotiated session", and "things that
we think don't"? Perhaps all we're really doing is handing a blob of data to
the application (which exists ABOVE the SIP layer), which then uses that
information to affect its own state, and may consequently affect the SIP
state?

In any case, I think there is a much deeper semantic problem lurking here
that we really haven't thought out.

--
Dean

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 30 Dec 2002 13:15:46 -0600

> well-documented things, define them as new methods. What does 

The ability to define a new usage without having to make code changes to
one's SIP stack, just as Events allows.

SIP, as you may have noticed, is a fairly complicated protocol. This has
given rise to the distribution of reusable (even open source) SIP stacks.
Personally I'm not up to hacking a new method (into, say, the Vovida stack)
everytime I want to deliver a new type of blob. INFO, constructed as I've
proposed, would let me implement a new INFO package on a stack without
having to rewrite the stack. We'd just need an API to tell the stack what
INFO packages we handled at the application layer, and it could do the rest
of the work without caring what data is being transported in the INFOs.
Events, you may have noticed, has exactly this property.

At some level, this is comparable to the "Why do we use MIME instead of
defining a new transport protocol for each and every possible type of data"
argument.

At its heart, INFO is for delivering APPLICATION SPECIFIC DATA within a
dialog. The SIP state machine does not have to care about that data, just
its delivery (although, as with SIP-T, the application itself may use the
data to influence the SIP state machine via the stacks's APIs). If SIP were
a proper transport protocol, we wouldn't have to define protocol extensions
for every application-specific datum.

I suspect that this working group has gotten very muddled between
"application" and "transport" layers. We have atendency to try and define
application semantics at the protocol level, and that's just wrong. The
protocol should define only protocol semantics.

--
Dean

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Dec 2002 12:56:22 -0800 (PST)

Dean,

I think the important part of the observation here
is that if SIP defines a way to transport data,
somebody really, really ought to define the
color/shape/consistency of that data too. To not
do that is to create interoperability problems by
definition. Now there is a management question of
_who_ defines those semantics -- eg, the SIP wg or
somebody else, but I don't think there should be
too much debate that it really ought to be done.
Opening up the door for un(der)defined semantics
seems really dangerous to me. A high energy
barrier for new semantics is probably a Good Thing
at this point as SIP is already a terribly
complicated beast. To end up with an official
backdoor for whatever kruft people want to wrap in
a SIP packet seems, well, like shortcut on the
road to hell.

	Mike

---

From: "Adam Roach" <[email-masked]>
Date: Mon, 30 Dec 2002 15:43:59 -0600

> of the work without caring what data is being transported in the INFOs.

So, your fundamental argument springs from the desire to have the API to
most SIP stacks include a function called something like
"registerNewInfoPackage" instead of  "registerNewMethod".

For some reason, that doesn't strike me as particularly compelling.

/a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Dec 2002 16:49:41 -0500

inline.

> one's SIP stack, just as Events allows.

Code to handle INFO goes somewhere.

> having to rewrite the stack. 

How is this different from allowing new methods, and passing off 
handling of that method to registered callbacks for each method?? Not 
different at all.

> We'd just need an API to tell the stack what
> INFO packages we handled at the application layer, 

Or, you could have an API to tell the stack what methods are handled.

> and it could do the rest

What work?? There is no semantics associated with INFO. None. Zero. 
Nada. Zip.

> Events, you may have noticed, has exactly this property.

The big huge difference I have been trying to point out is that EVENTS 
DEFINES SEMANTICS, whereas INFO doesnt.

> defining a new transport protocol for each and every possible type of data"

MIME provides semantics and syntax that are independent of the type.
SIP events provides semantics and syntax that are independent of the 
package.
INFO provides nothing.

> for every application-specific datum.

SIP is not a protocol for shipping data between applications. I do not 
think we should encourage the arbitrary transport of stuff in SIP.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Dec 2002 16:51:17 -0500

>   So... s/INFO/X-SIPPING and be done with it?

Sorry for being dense, but I don't follow what you mean here.

If you are asking whether I am suggesting that people define their stuff 
as new methods, then yes, that is what I am suggesting.

-Jonathan R.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Dec 2002 14:02:38 -0800 (PST)

> as new methods, then yes, that is what I am suggesting.

Sorry for being too flippant, but if we're going
to have a junk heap for undefined semantics, some
truth in advertising might be in order. Hence X-.

	 Mike

---

From: "Frank W. Miller" <[email-masked]>
Date: Mon, 30 Dec 2002 17:49:09 -0500

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.
[email-masked]