Subject: RE: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Aug 2001 02:03:16 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Thursday, August 23, 2001 8:12 AM
> To: [email-masked]
> Subject: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol
> 
> although one could argue it is still a mis-use of ideal SIP.  This is
> because it is still carrying a payload and not necessarily 
> initiating a
> 'session'  Unless the session is a human-based session, i.e. 
> "come here
> watson" or "can I ask you a quick question?" which would then 
> create the
> need for a 'session of MESSAGES' or physical appearance, 
> either of which
> SHOULD be handled by another protocol.

Perhaps you should take a look at SIP, which defines several methods that
have exactly ZERO to do with establishing a session (OPTIONS, BYE, REGISTER
in the base spec). OPTIONS, in particular, is the case that the value SIP
provides is the ability to address a request towards a user with a
location-independent name (sip:[email-masked]) and make sure that
this request is forward to the many places that the user may have a point of
communications. What SIP is really good at is this kind of human user
rendezvous. 

In the case of the paging model, there are two tasks at hand - (1) taking of
a location indpendent name, i.e., sip:[email-masked], and getting a
message to that user at the many places the user has a point of
communications, (2) the message should contain some content that is rednered
to the user. IMHO, the hard part of that problem is the routing of the
request towards the user. The easy part is sticking some payload in that
message. Since SIP already supports MIME payloads, SIP can provide the
paging model of IM pretty much as a freebie over its existing proxy
networks, which exist for the purpose of user rendezvous.

If you add to that the abilities SIP provides for user identification and
authentication, privacy services, call routing preference services,
multipart capabilities, and so on, all of which can be applied to the IM
paging model even, it seems that you get quite a lot of reuse.

This is why there was a substantial community that found the provision of
IM/presence with SIP to be a good thing, and so the group was chartered.

So, let us put these irritating statements about "don't use SIP for IM at
all", which appear to be in vogue on this list these days, to rest. The
point is moot.

> Jonathon R. would like to have end-to-end session of MESSAGEs 
> to travel
> between the clients directly as this supports the scalability 
> and original
> voice use of the SIP server.  On the other hand this doesn't 
> support the
> fundamental design requirements of IM as stated in rfc2779 
> 2.4.3/2.4.4.
> Which means, prior to supporting that end-to-end 
> communication, the SIP
> server would have to determine if 'that was allowed' based on 
> the security
> requirements Vasilis and Robert O have been talking about, 
> which is also
> required per rfc2779.

My preference is e2e. That doesn't mean its not possible to use
intermediaries, no matter what the transport. I'll note that the same exact
issues arise for voice and video.

> 
> Those fundamental services can be easily implemented at the 
> SIP server if
> SIP was the method used to send 'sessions of MESSAGES' - 

False. It is easy to do this independent of the transport. Processing-wise,
it is more intensive to do this with SIP, since SIP message processing is
far more intensive than the the TCP byte shuffling I have described in
previous posts.

> The intermediary/PROXY MUST be created and supported as a 
> basic feature of
> the IM 'session of MESSAGEs' design.

I agree it is a requirement that such a thing be possible. I think it is
easy to show that it is doable for any transport protocol.

> 
> In Robert Os case he would want the development of that 
> intermediary to play
> off of the domain and security information designed into the 
> SIP server
> (thus making it portable across SIP and the IM proxy).
> 
> This is easily designed if you have a unified 
> configuration-directory where
> the SIP Server and IM Message proxy pull configuration information,
> otherwise, it looks like a complex proposition.

I will comment separately on Robert's inter-enterprise-with-firewalls case.
But, I'll note that you've got a general problem here for all session
oriented protocols. If you put IM on the proxy path, well, that might be
easy, but voice will never work that way. Neither will video. Neither will
games. Neither will the new communications medium of next year. So, you can
solve this with a one-off solution that works for ONE, and ONLY ONE form of
communications (IM), or you can solve it in a more general way that enables
this domain security to be applied to all media types. The SIP view is to
solve these for all media types with a generic mechanism. I think that is
the right approach.

> In addition, to support end-to-end signaling the SIP server 
> needs to have
> logic on whether or not that end-to-end signaling is allowed 
> or whether it's
> end-to-end-to-end-to-end :) - this meets the rfc2779 2.4.3/4 
> requirement,
> regardless of natiness.

SIP doesn't specify what policy you put into your proxies. If you want to
introduce these intermediaries, you can. 

> Jonathon R. has some good solutions for the intermediary in 
> other IDs he has
> written, but the reality is the communication looks more like 'direct
> chatting' than text based audio/video conference, which is 
> why the IESG
> probably frowned on using RTP

No such thing happened. You might even want to take a look at RFC2793, "RTP
Payload format for text conversation". RTP is not a fit for IM for other
reasons.

> As an aside, I would also presume this is why sctp may not be 
> a necessary
> choice for the instant message 'signaling', to use a term 
> from voice drafts,
> given the sctp's primary use, albeit congestion management at the
> intermediary/PROXY.  IMs are only text per node, am I naive 
> to think it's a
> moot point or would there be congestion issues at the intermediary???

There will be lots of congestion with IM, which is why a congestion-control
enabled transport is required by IESG. In fact, IM could potentially be the
source of boundless congestion. Think about what it offers - end to end
transport of arbitrary content between peer users. I can think of a million
uses for that, many of which have little to do with instant messaging as you
know it. The developers of aimster have already seen this value, and there
will be others. This is why congestion control is so important, and this is
why I don't want my proxies in the path of 120Meg IM transfers. Let routers
do bit shuffling. Let proxies do rendezvous.

> 
> Lastly, Jonathon R appears convinced that the communication should be
> end-to-end.
> (http://mailman.dynamicsoft.com/pipermail/simple/2001-August/000606.html),
>but over TCP :)!  That works great if you are trying to scale the servers
>and you want to put two callers together, but with IM, it's not voice and
>it's like email, but more importantly, as stated in rfc2779, the
>security/control needs to be built in. 

Ultimately, the best security is afforded by a pure, session oriented end to
end model. I find it frightening that people associate privacy with sending
all of their messages to MSN/Yahoo/AOL/whomever for archival and
who-knows-what-else. The security community has long recognized the power of
e2e security vs. transitive chains of trust.

 I am just pointing out the
>'vision/scope' of rfc2779 that says 'when you are heads down discussing
>technical stuff, don't forget these requirements'  Jonathon didn't write
>that RFC2779 so he probably isn't thinking with that light bulb on.

I take personal offense at this. 

>I would not want to see the IMsession design based on 'phone-calls' as
>that's the 'way SIP has been predominatly used', but instead, to take a
>different and assuredly positive approach.

I could not disagree more. This group was formed because there is a large
community that believes that the right technical approach is to view
communications in the more general multi-modal (IM, voice, video, gaming,
etc.) context, rather than point solutions for each mode. Absolutely NONE of
the issues you raise applies to IM alone or voice alone, and I have pointed
these cases out explicitly above.

>I am not intending to offend anyone 

In that case, I would recommend that you refrain from personal insults, as
you have done above, as those usual cause people as myself to take offense.

-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

---

From: Vasilis Polychronidis <[email-masked]>
Date: Fri, 24 Aug 2001 04:39:33 -0700

> easy to show that it is doable for any transport protocol.

Jonathan are you planing to write an ID explaining how?
I would like to see all of the issues raised by myself and Robert O,
to be resolved with your proposal if possible.

---

From: Vasilis Polychronidis <[email-masked]>
Date: Fri, 24 Aug 2001 04:40:17 -0700

Kind Regards,

-Vasilis Polychronidis