Subject: Re: [Simple] Sessions of MESSAGEs

From: [email-masked]
Date: Mon, 20 Aug 2001 19:31:55 +0300

Assuming that the SIMPLE protocol will develop over time to give the same
functionality as current IM systems, the
restrictions imposed by inheritance from SIP bother me.

What I am bothered about is that SIMPLE inherits the separation between
signaling and media of SIP. It assumes a different transport for the
signaling and the media. For example, in a conference the signaling
(INVITEs/REFERs) should be done on a single TCP connection while a new TCP
connection should be created for sending the text messages of the
conference.

I am not sure if creating a new TCP connection for each IM (when it is done
by a session) or conference will scale. Maybe MESSAGE should be allowed to
be carried on the same transport as the INVITE message was sent on?

-Avshalom
Sametime/Lotus

                    "Peterson, Jon"                                                                                             
                    <[email-masked]>        To:     "[email-masked]'"                                
                    Sent by:                          <[email-masked]>                                          
                    [email-masked]        cc:                                                                       
                    icsoft.com                        Subject:     [Simple] Sessions of MESSAGEs                                

                    20/08/2001 17:47                                                                                            

After the SIMPLE session last week in London, the SIMPLE chairs received
some feedback from the IESG with regards to the use of the MESSAGE method
end-to-end when an IM session has been established with an INVITE (as
described in draft-ietf-simple-im-session-00).

The IESG has some concerns that this mechanism constitutes the use of SIP
as
a transport protocol. In other words, once the session has been established
between the two endpoints by the INVITE, if the MESSAGEs can only go
directly end-to-end, then their headers and related protocol apparatus are
entirely superfluous and may do more harm than good. We saw during the
meeting last week that there were definitely some pitfalls to allowing
methods other than MESSAGE across the IM stream (as well as questions about
overlapping transactions, redirection, forking, and so forth), and it isn't
clear that the overhead is justified if MESSAGE is just an envelope for its
encapsulated MIME payload. The IESG was particularly concerned, in addition
to the protocol overhead, with congestion characteristics of the messaging
session and with the precedent that could be set by using SIP in this
fashion.

For these reasons, the IESG is not inclined to look favorably on that
direction for our protocol work. They also weren't enthusiastic about the
potential use of RTP text for message transmission (significant concerns
were also raised on the floor in London about message framing, especially
at
CPIM gateways). The recommendation we've been given is to focus on a
standard transport protocol with understood congestion properties such as
TCP or SCTP. In London, Ben Campbell took an action item to begin
investigating alternatives along these lines given the significant concerns
that arose on the floor with regards to the other approaches. It seems that
the primary question about this approach is what runs over the transport
protocol in question; i.e. MIME headers and bodies, pure message/cpim,
BEEP,
plain text, etc.

If anyone feels strongly that we should continue to pursue the use of the
MESSAGE method for direct end-to-end IM signaling, or has input about how
the transport should operate, let's get this discussion underway promptly
so
we can meet our projected September deliverables.

Jon Peterson
NeuStar, Inc
SIMPLE co-chair

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Zane Thomas" <[email-masked]>
Date: Mon, 20 Aug 2001 09:57:36 -0700

Avshalom,

> signaling and media of SIP.

From my perspective that's a virtue.  It seems to me that SIP has a
well-defined purpose; locating peers for the purpose of establishing one or
more sessions.  I've never liked the idea of extending SIP to serve as a
transport for IMs, and particularly as a potential provider of a SIP server
I would simply refuse to carry MESSAGEs which may be arbitrarily large and
numerous.  I'm not interested in paying the costs to carry that traffic for
others.  I am interested in paying the price required to participate in a
distributed peer location system.

> by a session) or conference will scale.

You don't *have* to use TCP, it's possible to use UDP with some extra logic
layered on top.  But when it comes to scaling I wonder exactly what
potential problem you're refering to.  Any given system can create *many*
connections, and when I look at the number of people on my ICQ buddy list
the number of TCP connections I'm actually using for IM falls well below
that limit.

Zane