Subject: [SIP] SIP and World Domination

From: James Kempf <[email-masked]>
Date: Fri, 4 Aug 2000 11:03:18 -0400

Fellow SIP enthusiasts,

Lately there seems to be a tendency for claims to be made that SIP can solve problems being
addressed by various other working groups. HTTP, mobile IP, instant messaging, IMAP, the
list goes on. Now, maybe SIP is flexible enough to serve as a dessert topping and
a floor wax (and a paint remover, and....), but another possibility is that this is
part of the normal process at IETF. People who are enthusiastic and knowledgable about
a particular protocol that is beginning to see widespread success begin to look at what
other problems the protocol can solve, in some cases, making claims about the protocol
in areas where there are other protocols that do an equally well, if not better, job
in solving the problems, or the other prococols could be easily extended to do the job.

The problem with SIP is that it is being closely watched by the telephony standards community.
Unlike the IETF, they have a very different process of standards development, and so
they are not familiar with how IETF works. However, they *are* familar and very, very
comfortable with circuit switched, and so when they see claims about SIP being made for
solving all these problems, they tend to think that they can turn to SIP for everything,
and turn a SIP proxy into a switch, and define all their services in terms of the switch.

This is a particular problem when authors of seminal, standards track IDs or RFC-track
informational IDs make such claims. When the claims are being made by a second
year graduate student or MTS 2, they can be critically evaluated, but when they are
made by leaders in the SIP community, the telephony standards community tends to 
view them as being made by "the" IETF itself.

What would perhaps be somewhat more productive is if people who see problems with other protocols 
in regard to how they interact with SIP or real time media to participate in the appropriate 
working group and help to define the interaction rather than simply asserting that SIP
can do it better.

All right, that said, I've donned my asbestos suit (with noise and mouth filter to prevent
inhalation of asbestos fibers), let the flames begin.

		jak

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 04 Aug 2000 11:46:14 -0400

> list goes on. 

There are clearly two opposing problems here:

(1) invent new protocols or protocol stacks for each new "vertical"
application (the ITU approach, to some large extent)

(2) re-use a single protocol for things where there are better solutions
(HTTP certainly has suffered from this problem and SIP may or may not)

Part of the evolution of application-layer stuff is that things that
used to be nicely separated aren't. HTTP is used to retrieve email,
email is used to send web pages, etc.

I don't think anybody here wants to replace IMAP by SIP, say, but there
are certain problems that 

There's also the new danger that we'll have small devices dominated by a
single function rather than workstation OS that support a whole range of
things, from a web browser to an IMAP client. For these devices, it is
sometimes easier to "abuse" an existing protocol than implement a whole
other protocol. Thus, the temptation is rational, if dangerous is
unchecked.

There seem to be two possible dangers:

(1) Feature creep into SIP.

(2) Servers have to implement two ways of providing information, namely
the SIP way and the "native" way. (If you like, the WAP problem.) 

(1) is more likely to be self-correcting, since the pain and gain are in
the same community. (2) is where collateral damage is most likely.

Maybe we need to address the items in turns (and I'm guessing here at
the overlap issues that you might object to):

HTTP: the line seems to be that as long as HTML or other "web" content
is part of the signaling exchange, this seems about as useful and
necessary as sending HTML in web messages rather than pointing to a web
URL. If there's an existing web server and URL, referral seems much
better. I don't see much temptation to venture there.

IMAP: I assume this is about message indication. There is indeed a
dangerous slope there, but one that industry seems to have slid down
long before us. (See the Yahoo instant messages when email arrives.)
IMAP is poll, so there does seem to be a need for notification, but not
retrieval.

Mobility: I see some value here for SIP for service and personal
mobility, but not as a replacement for mobile IP, except where mobile
IPv4 with binding isn't available. (The sentence doesn't make sense, but
there's a difference between a protocol being available in an RFC and
being available where I work or get my ISP service.)

IM/presence: Not sure if you're specifically referring to IM or presence
(the two seem rather different to me), but I don't think I have to add
to *that* discussion. 

Maybe a bit more precision on your part would be helpful.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Aug 2000 17:42:01 -0400

> and turn a SIP proxy into a switch, and define all their services in terms of the switch.

This is certainly one of the dangers. Henning has outlined others. More
generally, I believe that the continued abuse of SIP for all these other
areas will end up in a protocol that is so complex that people are
afraid to implement it, and with so much stuff and extensions, no one
can sort out what they do and don't need to solve their problem. What
scares me the most are interdependency of extensions, especially ones
that are very distinct (see the other thread on the proposed usage of
MESSAGE for device control). These are the things that can very quickly
bring SIP towards a death of contorted complexity.

To date, we have kept SIP limited to the field of initiating,
terminating, and modifying communications primarily between people (or
their automated agents like answering machines). All the accepted
extensions in the SIP wg relate to this general field. 

I like SIP. I have dedicated a lot of time to it, and I want to see its
successes continue. It is because I believe in it that I have, and will,
continue to fight against uses which fall outside of its core
application. Now, what people do in their labs and in conference papers
is their own choice, and I'm happy that they experiment with SIP. But,
bringing it to IETF is a much more serious affair, and I think we need
to be very careful here.

Someone once told me that most startup companies don't die from
starvation, they die from indigestion. I think we can possibly argue
this here. I don't worry about SIP dying from starvation. But now I do
worry about it dying from indigestion.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Stan Moyer <[email-masked]>
Date: Sat, 05 Aug 2000 20:55:19 -0400

>bring SIP towards a death of contorted complexity.

I think this is a terrible example. The proposed usage of MESSAGE for device
control (see draft-moyer-sip-appliances-framework-00.txt for those not
following this thread) does not propose any extensions or modification of SIP
(beyond the impp drafts). In fact, a SIP Proxy that was written to handle the
MESSAGE (and other Presence) extensions would not even know the difference
between a MESSAGE sent for Instant Messaging or one send for device
communications/control. In fact, neither would a SIP UA client/server stack --
it's only the end application above the UA layer that would have to handle
things differently. I don't see how that adds to the complexity of SIP (unless
I am missing something).

>extensions in the SIP wg relate to this general field. 

But is it really that much of a stretch to communicate between
devices/appliances instead of people? You refer to automated agents -- I
believe many devices/appliances are simply automated agents for people.

>bringing it to IETF is a much more serious affair, and I think we need

I think that is a noble cause and a good idea, but we do need to be careful
what we rule out just because at first glance it does not appear to fit its
core application. There is certainly a benefit to the overall acceptance of SIP
by extending the scope of services it can support if it does not increase the
complexity.

-Stan

Stan Moyer 
Director, Internet Services Infrastructure Research 
<[email-masked]>; Telcordia Technologies, 
MCC-1A238R, 445 South Street, Morristown, NJ 07960-6438 
voice: +1 973 829 4923; fax: +1 973 829 5889 
http://www.argreenhouse.com/bios/stanm/