Subject: [SIP] a proposal for a way to compromise? (really, not a joke)

From: Scott Petrack <[email-masked]>
Date: Wed, 2 Aug 2000 14:39:41 -0400 (EDT)

[The following is written in haste, because I discovered I have to take an
early plane out of the IETF. I'm really sorry to miss the BOF tonight, but
I'll certainly answer email questions:]

I tried hard to do what Dave Crocker suggested, and thought about what the
'other side' is really after, and the fact is that once I put myself in
this frame of mind, I came pretty quickly to a few ideas that point to a
compromise. I know that this is considered impossible, and that many
people are just waiting for the two weeks to pass so that the group can
split in two, but I hope you'll give the following ideas a decent
look-over. I'll state up front that I am guilty of two things: I am from
the SIP side of the house, and I have not been as active on the list as I
should have been. But I spoke to a few people yesterday, and I believe
that the following is new input. If not, I apologize.

First, Dave Crocker's exercise: what does each side bring to the table,
beyond "take my protocol, please...."

The really essential service that SIP offers is 'session initiation'. It
was absoutely designed from the beginning as a way to HAND OFF to another
protocol. SIP is only one piece in a puzzle that includes SDP (for
describing voice/video sessions) and RTP (for transmitting realtime data).
The original intent was that SIP would hand off to the actual media
transport session as soon as possible
(an RTP session in the case of realtime voice/video). In fact, basic SIP
(without extensions) does a relatively poor job of managing or modifying
sessions that already exist. 

The key thing to remember from all this is that SIP is 
crafted to allow the sort of "finding"/"signaling" and "hand off to
another protocol". It is designed to do this under some very important and
difficult conditions -- mainly when people and terminals are moving
around, and when it's not clear at the beginning the people want to IM.
What SIP is less designed to do is to pass around crazy types of
text and non-text instant messages (although of course SIP can do
*anything* ;-)) that have nothing to do with a later hand-off to a
multimedia session.

Now, on the other hand, my understanding is that the "messaging" people
feel that the key elements of MIME and SMTP push are very important to
them. In fact, my understanding is that the 'mobility rendez-vous parts'
of IMXP are less established and tested yet than various nooks and
crannies of the problems of getting a message reliably and quickly from A
to B.

I for one think it very reasonable to suppose that people who have been
thinking about how to do messaging for many years are very good at their
craft, and have thought a lot about the nooks and crannies of the
different horrors that might occur when trying to transport "instantly"
different types of "messages". Maybe they've even thought more than the
SIP people have about this ;-). I'm particularly thinking about what will
happen when the message is large (a big image or large HTML message, etc.)

So my proposal for compromise is the following:

use SIP for rendezvous and distributing presence -- find the other
person/people, help decide that the *way* they want to communicate is via
IM, and then HAND OFF to an IM protocol, one that is designed to be
extensible to all kinds of instant messaging (large gifs, powerpoint
presentations, shared browsing, whatever, etc.).

If IMXP is a better "IM transfer protocol", then it's very
reasonable to leave it to do just that, and have a user signal that
he wants to IM you by having the SIP hand off to IM. 

I'm hoping (probably in vain) that what really offends the SIP people is
doing finding/rendezvous in some other protocol than SIP, and that what
really offends messaging people is using SIP to transfer messages.

To be honest, this already happens in one very special kind of instant
messaging -- people who are into telephone devices for the deaf (TDD) have
defined an RTP format for realtime delivery of text. If you've ever seen a
device like this, it is the original "instant messaging device". It
enables people who could not otherwise use a phone to communicate over the
phone. And in the SIP version of this service, SIP is used to 'set
up' the call, but soon enough the call is handed off to RTP, using the
special RTP format for these kinds of text messages. NO NO NO -- I'm not
suggesting that we do instant messaging this way. I'm suggesting that this
model -- where SIP rendez-vous and hands off to a different protocol -- is
the core SIP model, and already is used for a very special kind of
"instant messaging". SIP really does this "find/rendezvous/hand-off"
piece very well, and it would be silly to reinvent it.

At this point, I think that it's worth saying that the accusations about
"SIP taking over the user" are really not true. There are many many things
that one might want to do with a user which have nothing to do with
communicating with her/him. I might want to configure the user's computer
(if I'm the sysadmin), I might want to send mail to his telephone,
whatever. SIP has indeed been designed for the
particular issue of "I've got a user name, and I want to do realtime
communication with him". SIP is not intended to 'own the user'. *That* is
a directory problem, and SIP is NOT a directory service, nor was it ever
intended to be one.

As a final comment (I'm sure I'm gonna regret saying this), it does look
as if IMXP is a less mature protocol, in the good old IETF sense of
multiple interoperable implementations. (remember "running code". That was
supposed to carry some weight). So for the really stupid requirement to
send a short piece of text from one host to another, the MESSAGE method 
works just fine. This could be used as a stop gap while the more elaborate
IMXP details are being worked out. There are many details still to be
worked out in the SIP proposals for rendezvous and presence. But they
really are details, and I'll bet that this work could be completed
quickly, to be followed by completing the work on finishing details of
IMXP for instant message delivery.

Scott

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

---

From: John Stracke <[email-masked]>
Date: Thu, 03 Aug 2000 14:59:11 -0400

Scott Petrack wrote:

> IM, and then HAND OFF to an IM protocol,

This makes great sense *if* the IM stuff you want to do is session-oriented.
We should remember that IM does not necessarily mean chat; it should be easy
to send someone a message without setting up a session.  (To use my
motivating example: a calendar sending someone an event notification just
wants to send the message; it doesn't expect a reply [and can't handle one in
any event], so setting up a chat session would not be helpful.)

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Peace, justice, morality, culture, family,   |
[email-masked]|sport, and the extinction of all other life  |
|                |forms!                                       |
\==============================================================/

---

From: Scott Petrack <[email-masked]>
Date: Sun, 6 Aug 2000 02:59:27 -0400 (EDT)

Well, for these non-session-oriented exchanges 
SIP people just made the "MESSAGE"
method. This is designed to use the
usual mobility infrstructure of SIP to deliver the message to the correct
endpoint(s).

If you just wanna find the endpoint and deliver some MIME content once,
I'm not sure there's much room for differences. Except that there are a
lot of useful things you'd probably want which SIP does already (mainly
mobility and delivery to many people at once, delivery to many instances
of 'you').

So I guess I was thinking about the other cases.