Subject: My Comments on SIP

From: Yaron Goland <[email-masked]>
Date: Tue, 28 Apr 1998 01:11:23 -0700

As promised here are my comments. I figure dumping a 15 page e-mail wouldn't
be terribly productive so I have split it up into several e-mails. Note that
this file was originally a Word file. If you would like that file just send
me e-mail.

BTW these comments are based on version 5 of the spec.

1 SIP and HTTP/1.1

My interest in SIP has absolutely nothing to do with what SIP was designed
for, IP telephony and related technologies. SIP, H 323, etc. are all
completely foreign to me. Rather my interest is strictly based on SIP's
solutions to certain problems that are facing the HTTP community today.

As such you will find that my comments do not address SIP's ultimate purpose
of sending session invitations. Rather these comments address the underlying
infrastructure that SIP had to create in order to implement its desired
functionality.

The ultimate goal of this paper is to make SIP's infrastructure available
for all users of HTTP.

I believe that SIP would benefit greatly if it choose to become HTTP
compliant. Specifically, it would be able to leverage the existing server
and client side HTTP development infrastructure as well the deployed
security and proxy infrastructure. Additionally it would benefit from the
many enhancements different groups are making to HTTP.

If SIP should decide to not become HTTP compliant then rather than lose the
great work that has been done in SIP, a group of us will most likely take
the spec, split it up as I specify below and work from there. Given how
closely SIP provides many of HTTP's needs, it would be silly to just throw
this great work away.

I think that would be unfortunate. It would most likely rob us of access to
the expertise that created the spec in the first place and it would condemn
the SIP protocol to live in a weird netherworld of being almost HTTP
compliant but not quite.

While there are some costs to becoming HTTP compliant, I have done my best
to explain them in detail below, I believe they are well worth paying.

		Sincerely,

				Yaron Y. Goland

2 Four Way Split

The SIP spec represents four different sets of functionality, Encryption,
UDP/Multicast, Notifications, and SIP.

I believe that physically separating the SIP spec into four component specs
would better server the needs of the Internet community by allowing each bit
of functionality to be examined on its own merits and to be leveraged,
independent of the others, by those who needed the functionality.

2.1 Encryption Header

Encryption deserves a specification of its own so that it can be carefully
considered independently of SIP. As specified today the encryption header is
compliant with HTTP/1.1. As such a separate spec would provide a definition
that can be leveraged by both HTTP/1.1 and SIP.

2.2 UDP/Multicast

HTTP desperately needs a spec that describes how to send HTTP over UDP and
Multicast. You have created in SIP the foundation for that spec. You would
be doing the universe a great favor if you broke this functionality out into
its own spec so everyone could leverage it. BTW this spec would contain ACK.

2.3 Notifications

Just change the header "call-id" to "reg-set" or "notify-id" or whatever and
you have a fully scalable notification system that can handle point to
point, multicast, UDP, single party and multi-party notifications. What is
the difference between INVITE and NOTIFY? Nada. This spec would contain the
Cancel and Register methods.

2.4 SIP 

SIP is built on the three previous sets and basically adds the BYE and
INVITE.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 May 1998 22:42:35 -0400

> this file was originally a Word file. If you would like that file just send

We anticipate pushing out the next "official" next revision of the spec
tomorrow (really - I'm glad I'm not subject to the late penalties I
assign on homeworks...). My rough estimation is that while the HTTP
convergence may be of some interest, the fear of adding further delays
by requiring the agreement of non-MMUSIC bodies (such as the HTTP WG) to
the use of multicast, etc. in HTTP is just too great.

If it is just a matter of splitting the spec, this can be done at
leisure (and the pace that the HTTP WG finds acceptable).

I'm particularly worried since use of multicast with HTTP raises a range
of other, potentially controversial issues (long responses, etc.) that
are non-issues for the intended SIP applications.

Since even a simple question (status and timeline of the HTTP rough
equivalent of Require:) has not been answered in several weeks, I'm
doubly concerned.
-- 
Henning Schulzrinne   [email-masked]
Dept. of Comp. Sci.   ph  +1 212 939-7042
Columbia University   fax +1 212 666-0140
New York, NY 10027    http://www.cs.columbia.edu/~hgs