Subject: RE: [Simple] Sessions of MESSAGEs

From: [email-masked]
Date: Wed, 22 Aug 2001 13:27:21 +0300

I agree with Robert.

If we want SIMPLE to be widely deployed and not remain in the PR pages we
must learn from the experience of existing communities. If SIMPLE will not
be optimized, I assume that pure SIMPLE will be implemented only between
communities while the client will remain proprietary in order to be able to
create communities that really work.

SIP was built for negotiating media (usually heavy) sessions. Trying to
leverage SIP into the awareness/IM area will require some adjustment in SIP
in order to be deployed in very large communities. One very important
requirement in large deployments is limiting the number of TCP connections
that server farm has to handle. Additionally when the protocol is tunneled
over HTTP it is not always possible to create many connections from the
client to the server, as the server and proxies limit the number of
simultaneous connections from a client.

Consider the case where a user is on several chats. Not enabling MESSAGE on
the control protocol will require creating a different TCP connection for
each chat I am in. I am assuming that the chat is handled by a chat server.
It might be acceptable for small communities but not for big ones.

avshalom
Sametime/Lotus/IBM

                    "Robert Brown"                                                                                              
                    <[email-masked]>           To:     "Jonathan Rosenberg" <[email-masked]>, "Vasilis          
                    Sent by:                          Polychronidis" <[email-masked]>, "Robert Osborne"     
                    [email-masked]        <[email-masked]>                                           
                    icsoft.com                        cc:     "Zane Thomas" <[email-masked]>, <[email-masked]>  
                                                      Subject:     RE: [Simple] Sessions of MESSAGEs                            
                                                                                                                                
                    22/08/2001 03:27                                                                                            

OK.  I understand your proposal.  Yes, I think we were talking past each
other.

However, I am concerned that such an approach will not be widely
deployed, as it also requires deployment of a firewall/NAT traversal
server (such as draft-rosenberg-sip-entfw-02) adjacent to every
firewall/NAT that exists between two end points.  In other words, if the
assumption is that there is a server in the public network, this will
only work for Internet-based services (like MSN and AOL) or for
organizations with liberal-minded firewall administrators (rare by
definition).

An in-band solution will be far more deployable, as it requires all the
common problems (like routing, authentication, firewall configuration,
etc) to be solved only once.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, August 21, 2001 12:23 PM
> To: Robert Brown; Jonathan Rosenberg; Vasilis Polychronidis; Robert
> Osborne
> Cc: Zane Thomas; [email-masked]
> Subject: RE: [Simple] Sessions of MESSAGEs
>
>
>
>
>
> > -----Original Message-----
> > From: Robert Brown [mailto:[email-masked]]
> > Sent: Tuesday, August 21, 2001 3:13 PM
> > To: Jonathan Rosenberg; Vasilis Polychronidis; Robert Osborne
> > Cc: Zane Thomas; [email-masked]
> > Subject: RE: [Simple] Sessions of MESSAGEs
> >
> >
> > Huh?
> >
> > I don't see how this is anything like how the web works.  Very few
web
> > users have certs for TLS, except for a very few specialized
> > cases where
> > they are used for user auth.
>
> I think we are talking past each other.
>
> In my proposal, there *is* a server in the public network. This server
is
> needed for nat traversal if both are behind a nat. In that case, each
> client
> would have a tls connection to that server, and it is only the server
> which
> needs to have a cert. This is standard web stuff, and thats what I was
> talking about.
>
> In the case of direct communication between clients, yes, this will be
an
> issue for TLS as it would require client certs, which is not that
common.
> This is a problem shared by all e2e encryption/authentication
mechanisms.
> There is work on defining SDP extensions for negotiation of session
keys
> (primarily for SRTP), and some of the key management mechanisms don't
> require certs, but rather, just shared secrets. It would be nice to be
> able
> to use that key management stuff for transport beyond SRTP, such as
> whatever
> we define for IM.
>
> However, if you want secure IM and trust that server in the cloud, you
can
> simply elect not to use direct communications even if possible. The
> signaling mechanisms in entfw and the drafts it depends on (i.e.,
comedia)
> support that.
>
> So, you get best of both worlds, from what I can tell....
>
> -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: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Aug 2001 09:31:41 -0400

There is a related issue that I have not seen discussed much: how a
Session of MESSAGEs is established and managed in the context of call
control. 

draft-ietf-simple-im-sdp-00 proposed some SDP extensions so that a
Session of MESSAGEs could be negotiated like any other medium. But I
have seen no further discussion of that in this context. Do the
proponents of Sessions of MESSAGEs agree that use of
draft-ietf-simple-im-sdp-00 or something similar should be required to
establish a session?

Regardless of whether IM Sessions are carried via Sessions of Messages
or some other way, I think there is a essential requirement that those
sessions be established via a standard INVITE sequence exchanging a
session description in SDP.

	Paul Kyzivat
	Cisco Systems

P.S. I think the title of this thread is wrong - it ought to be
something like "IM Sessions". A Session of MESSAGEs" is one way to
realize an IM Session, and this thread seems to be discussing the pros
and cons of that vs. other ways of realizing an IM Session.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 22 Aug 2001 09:46:39 -0500

> draft-ietf-simple-im-sdp-00 or something similar should be required to

The draft you mention was specific to sending IM messages using a SIP 
transport. Since the IESG has recommended against that approach, the 
draft is no longer particularly relevant.

> session description in SDP.

That is our intention.

---

From: "Robert Brown" <[email-masked]>
Date: Mon, 27 Aug 2001 10:31:54 -0700

RE-activating this thread as I believe it is too important to be ignored.
Because it needs a firewall traversal box (like entfw-02 or myriad other
designs), which most enterprises will not deploy, the current messaging
proposal is not suitable for the enterprise and will be undeployed in
enterprise networks.

I did not say enterprise networks will not deploy SIP-based instant
messaging.  I would prefer that they deploy an IETF protocol than a
proprietary one.

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, August 22, 2001 3:27 AM
Subject: RE: [Simple] Sessions of MESSAGEs

>                     <[email-masked]>           To:     "Jonathan
Rosenberg" <[email-masked]>, "Vasilis
>                     Sent by:                          Polychronidis"
<[email-masked]>, "Robert Osborne"
>                     icsoft.com                        cc:     "Zane
Thomas" <[email-masked]>, <[email-masked]>
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>