Subject: RE: [Sip] INFO considered harmful

From: Adam Roach <[email-masked]>
Date: Thu, 2 Jan 2003 18:00:27 -0600

> From: Frank W. Miller [mailto:[email-masked]]
>
> [T]he reality is, application implementors need some kind of
> app-to-app tunneling for stuff that isn't explictily handled. 

I'm trying to understand this argument more clearly.

It sounds to me like you need some sort of session of application-
specific information that you can use to communicate between two
nodes.

Perhaps using some sort of protocol to initate this session
would be appropriate. You'll also needs a protocol of some sort
to describe it, probably carried as a payload in this session
initation protocol. Ideally, this session description protocol
could leverage IANA-registered media types to describe the content
of such sessions, so that an infinite number of types of sessions
can be described.

Hmmm...

/a
_______________________________________________
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: "Frank W. Miller" <[email-masked]>
Date: Thu, 2 Jan 2003 19:37:35 -0500

Heh.

What I'm referring to is the need for implementors to build upon the basic
signaling mechanism that SIP provides.  If an application has signaling
needs that are not met with the basic protocol constructs, application
implementors need a way to make it happen.  As others have argued, there are
instances where augmenting the (perhaps third party) SIP stack source code
with new methods does not make sense.  This can be expensive and
time-consuming compared to say, punting an INFO body written in XML to an
open source parser.  The ability to get something like this done quickly
and/or without perturbing the SIP stack code is very important, despite your
sarcasm.

FM

Frank W. Miller, Ph.D.
Chief Technical Officer
sentitO Networks, Inc.
[email-masked]

----- Original Message -----
From: "Adam Roach" <[email-masked]>
To: "'Frank W. Miller'" <[email-masked]>; "Jonathan Rosenberg"
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 02, 2003 7:00 PM
Subject: RE: [Sip] INFO considered harmful

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 3 Jan 2003 16:06:58 -0600

My mother said I should stop inflaming things, but here I go again anyhow.
Sorry, Mom.

Adam said, responding to Frank in our long-winded exchange:
> would be appropriate. You'll also needs a protocol of some 
> sort to describe it, probably carried as a payload in this 
> session initation protocol. Ideally, this session description 
> protocol could leverage IANA-registered media types to 
> describe the content of such sessions, so that an infinite 
> number of types of sessions can be described.

Actually, Adam and I just had a conversation about this argument. I think
actually that there is something hiding in here which is THE HEART of almost
every philosophical debate we've ever had in SIP. If we can get this nailed
down now, we'll be preventing a HUGE number of future fights.

Or in short: Boom! Epiphany! I think I understand what we're arguing about.

I'll admit -- Adam's been philosophically consistent in his arguments since
day 1.  He believes that SIP should start sessions, stop sessions, and
nothing else.

Examples:

Lets look at "events". By Adam's logic, the event system should consist of
sending an INVITE (instead of a SUBSCRIBE) to the event source. The SDP body
(Only SDP should be allowed in INVITE) would descibe the events being
requested and the protocol, IP address and port number on which the
subscriber would be listening. The 200 OK response from the event source
would then contain the protocol, IP address and port number to which the
subscriber should send acknowledgements of notifications, assuming that the
notification-transport protocol (clearly, not SIP).

And Whoa! Look at REGISTER. That doesn't set up any kind of session! It's
clearly not a SIP function. We should instead use an INVITE to set up a
"registration session", over which we would then use a registration protocol
to establish registrations.

MESSAGE is clearly divergent. By Adam's logic, only message sessions should
be used. By similar reasoning, INFO is also off, and instead SIP-T should
use INVITE to establish a sigtran session.

This actually all makes sense and hangs together philosophically.

The problem is, the working group diverted from that philosophy a long time
ago. What we have now is a combination of three transactional protocols
(REGISTER, OPTIONS, MESSAGE) with a session-establishment protocol (INVITE)
which supports several in-session request verbs (UPDATE, OPTIONS, ACK, INFO,
MESSAGE, BYE, PRACK, etc.) and another session-establishment protocol
(SUBSCRIBE) which supports an in-session request verb (NOTIFY). We've also
defined an intermediation framework (the SIP Proxy) and a set of end-to-end
and hop-by-hop authentication and integrity protection mechanisms that can
be used for all these protocols. Really, it's the intermediation framework
that gives SIP most of its utility.

Ok, it could be tidier. But it is very powerful, fairly complete, and
actually works. And yes, the combination effectively provides a very useful
transport protocol that does all sorts of things that HTTP alone can't do,
such as intermediated rendezvous. And no, it DOESN'T just do phone calls
(making attempts to model proxy load based on telephone switch metrics
hopelessly bogus).

So my humble suggestion: Get over it. Iron out any kruft that makes SIP less
desirable as a transport protocol (like UDP), and get on with the business
of making stuff that people can use to get their jobs done. Stop complaining
that your proxies are getting loaded down by serving a useful purpose to
somebody, and start understanding what that purpose is and how to charge for
it.

If you don't like it, fine. Let's take out a poll on deprecating REGISTER,
MESSAGE, SUBSCRIBE, INFO, PRACK, SUBSCRIBE, NOTIFY, and all that other
stuff.

Or hey, just toss it all out and add session negotiation to XMPP. 

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 03 Jan 2003 17:43:41 -0500

Dean,

The lines are not always so black and white. Its not a choice between 
"do anything" and "do nothing but INVITE". There is a line somewhere 
about what is a good use of sip, and what is not. We have some 
documents, even, which help to identify that line (SIP guidelines), and 
no doubt it has moved over time. Indeed, there were even arguments about 
whether BYE belonged in SIP, since clearly its not needed for 
"initiation". However, if you buy the assertion that SIP needs to at 
least manage the session, that clearly includes termination as well as 
initiation. These days, I know of very few folks (only one in fact) that 
would argue against BYE as part of SIP.

I still stand by my assertion that many of the usages of SIP INFO are 
over that line, and that in order to keep the usages in a line we are 
comfortable with, something has to be done.

-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