Subject: RE: [Simple] Sessions of MESSAGEs

From: "Robert Osborne" <[email-masked]>
Date: Mon, 20 Aug 2001 12:45:51 -0700

Hi,

I still do not understand why we need to force sessions of
MESSAGEs to have to go via a special media channel. Using the current
draft if you wish to avoid congestion or server load, it is possible 
for the MESSAGEs to go peer to peer. If there is a firewall in
between the peers, then the traffic can be forced to go through
the signalling path. 

By forcing MESSAGEs to always go via a seperate connection we are
introducing severe constraints that will block deployment of IM
solutions. Why would a company deploy a server to allow for 
federated presence, have to deploy another server to get the IM
through the firewall? In reality they shouldnt need to, they should
be able to use the same server.

In reality the amount of traffic caused by an IM session is
insignificant when compared with that of presence, so why is there
such a major concern? Why not force a NOTIFY to have it's own
connection?

Rob O

>-----Original Message-----
>From: Jonathan Rosenberg [mailto:[email-masked]]
>Sent: Monday, August 20, 2001 10:49 AM
>To: Robert Osborne; Peterson, Jon; [email-masked];
>[email-masked]
>Subject: RE: [Simple] Sessions of MESSAGEs
>
>
>
>
> 
>
>> -----Original Message-----
>> From: Robert Osborne [mailto:[email-masked]]
>> Sent: Monday, August 20, 2001 1:17 PM
>> To: Peterson, Jon; [email-masked]; 
>[email-masked]
>> Subject: RE: [Simple] Sessions of MESSAGEs
>> 
>> 
>> Actually I was referring to the session of MESSAGEs and not the
>> paging of MESSAGEs. 
>> 
>> The scenario that always strikes me as being a priority is 
>> that a employee
>> of Company A, wishes to communicate with an employee of 
>> Company X, who supplies
>> parts to Company A. Irrespective of wether this IM session is 
>> paging or not,
>> both employees will want to ensure that it is secure, encrypted and 
>> authenticated session that easily traverses firewalls.
>
>I agree with those requirements (and in fact included them in 
>my list of
>requirement), but I do not see why the solution has to be 
>"send IM over the
>proxy networks". The security story is probably better with the session
>model, using a separate transport, since you can negotiate 
>session keys e2e
>for the stream. I agree that the fw/nat traversal is important; I think
>there are sensible ways to deal with it which do not require 
>using the SIP
>proxies for message transport.
>
>-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: "Zane Thomas" <[email-masked]>
Date: Mon, 20 Aug 2001 12:58:02 -0700

Robert,

> be able to use the same server.

You're assuming a server-centric model, presence and IM could be carried
directly by a peer network having its own builtin firewall solutions.  The
one thing p2p solutions need is some way to find at least one peer, SIP
seems to me to serve that goal nicely.

Zane

---

From: Vasilis Polychronidis <[email-masked]>
Date: Mon, 20 Aug 2001 14:12:15 -0700

Hi Rob,
Reading the mailing list is apparent to me that the consensus in the group
is not to use the MESSAGE method and consequently SIP as the transport
protocol for IM sessions.
I hope the above answer your first question.

As far as your second question (about presence events) it seems to me that
presence events are more closely related to signaling (SIP) however I agree
that
they may create congestion issues.
I think the group should seriously consider the proposal put forward by
Michael Hammer.
Personally I think assigning different priorities to presence messages is an
excellent idea.

BR,

-Vasilis Polychronidis

Robert Osborne wrote:

> _______________________________________________
> simple mailing list
> http://mailman.dynamicsoft.com/mailman/listinfo/simple