Subject: [Simple] Is SIP too restrictive for SIMPLE?

From: "Avshalom Houri" <[email-masked]>
Date: Fri, 31 Aug 2001 13:11:11 +0200

[Sending from a different email due to mailing list DNS problems]

Looking back, there were a lot of discussions in the IMPP group if SIP is
adequate to be a protocol for IM and presence. There were a lot of
discussions on the volume of the SIP protocol etc.

If we look at SIMPLE as an extension of SIP without regarding the special
needs of IMPP then there seems to be some problems:

* SIP is a transport protocol while SIMPLE is an application protocol -
Where the transport area considerations end and the application
considerations start? For example, the mandate of the IESG not to send
MESSAGE in a session seems to come from transport considerations and not
from applications considerations.

* SIP is geared for creating sessions, it might suffice for current
definition of IMPP but when trying to extend it, new methods will be needed,
the SIP protocol might be need to be "contaminated" with methods that are
far from the intention for what SIP was created. Will it be possible? Will
every method need the approval of the SIP group?

Maybe the relationship between SIMPLE and SIP should be defined as less
restrictive? I am not sure if there are precedencies to such cases that we
can learn from.

avshalom

Sametime/Lotus/IBM

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 31 Aug 2001 12:21:17 -0400

> -----Original Message-----
> From: Avshalom Houri [mailto:[email-masked]]
> Sent: Friday, August 31, 2001 7:11 AM
> To: [email-masked]
> Subject: [Simple] Is SIP too restrictive for SIMPLE?
> 
> 

No, of course that is not true. SIP is standardized within the transport
area, and SIMPLE within the applications area. The presence of SIP in
transport is more historical than anything else. RTP was the first "voip"
working group, and since it really is a transport, it was in the transport
area. As other groups got added, mmusic, iptel, pint, spirits, sip, sipping,
megaco - they all went into transport since that was where the voip work
was. Would you say megaco was a transport protocol? Hardly. Neither is SIP.

> from applications considerations.

There has always been coordination between the applications area and
transport. I recall that early on, the impp group was going to get feedback
from the transport area on transport issues related to IM and presence. Such
feedback was to help make sure that the application protocols properly took
congestion control and transport into account. We have just gotten some
feedback, as was the goal in the first place.

> every method need the approval of the SIP group?

This is really nothing more than FUD.

SIP has a whole lot of extensibility built in. New methods, new payloads,
new headers, the Require/Supported framework, new response codes, etc. These
seem more than adequate for new stuff and have been more than adequate to
handle the currently proposed extensions. If you have a specific concern
about these not being sufficient for future needs, please post a specific
concern.

Arguably, the SIP group has been too willing to accept proposed extensions,
rather than too restrictive. The approval of the SIMPLE working group
clearly shows that there is IETF commitment to making sure this thing works.
By closely aligning IM and presence treatment with voice, video, and other
things, you have good assurances that future IM needs (which are likely to
mirror voice needs) are met. Examples would include conferencing, privacy,
thid party control, etc., all of which you will get for IM for free via
inheritance from SIP.

Can you please point out specific concerns you have? 

> restrictive?

What does that mean, exactly?

-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