Subject: [Simple] MESSAGE session

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Fri, 07 Sep 2001 15:54:07 -0400

While the use of MESSAGE-based sessions over UDP is 'out', I wonder
whether this also implies that MESSAGE over TCP is unacceptable. It
seems to satisfy the minimum requirements for any mechanism:

+ congestion and flow control
+ no size limitation for bodies
+ each message must allow a different content type
+ support of multipart MIME bodies
  for easy gatewaying to email, among other reasons
+ allow use of TLS (or similar) for security
* if possible, avoid yet more parsers
* extensible, i.e., allow additional labeling through
  headers (useful for various gateways)
* possibly make use of existing compression mechanisms
* allow multiplexing, i.e., re-use one "pipe" for multiple
  sessions (this simplifies various mixing functions, for example) 

(+ are, in my view, must-haves, while * are nice-to-have)

I'm way backlogged on email, so my apologies if this has been discussed
to death.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Zane Thomas" <[email-masked]>
Date: Fri, 7 Sep 2001 13:12:20 -0700

> seems to satisfy the minimum requirements for any mechanism:

Fyi, I'm finding beep (www.beepcore.org) to be an interesting transport
protocol.  My hypothetical (at this time) scenario has me locating users
with sip and establishing a beep session.  Beep supports multiple logical
channels over a single tcp connection, ssl, and can easily be proxied in a
many-to-many fashion.

Zane

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 10 Sep 2001 08:57:10 -0400

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Henning G. Schulzrinne
> Sent: Friday, September 07, 2001 3:54 PM
> To: [email-masked]
> Subject: [Simple] MESSAGE session
> 
> 
> While the use of MESSAGE-based sessions over UDP is 'out', I 
> wonder whether this also implies that MESSAGE over TCP is 
> unacceptable. It seems to satisfy the minimum requirements 
> for any mechanism:
> 
Yes, it does. 

At first blush CPIM-over-TCP would seem to have the same properties and
avoids a bunch of gatewaying issues, assuming SIMPLE endpoints would
need a CPIM parser anyway.

I'm not sure I would consider your last bullet about multiplexing an
advantage as I'm usually a skeptic about application-specific TCP
multiplexing schemes. If you really need this SCTP would seem an
attractive alternative.

> I'm way backlogged on email, so my apologies if this has been 
> discussed to death.
> 
> 
> -- 
> _______________________________________________
> simple mailing list
> [email-masked] 
> http://mailman.dynamicsoft.com/mailman/listinf> o/simple
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 10 Sep 2001 08:55:04 -0400

> need a CPIM parser anyway.

Is this a real format as opposed to a meta or abstract format?

The value depends also on the likelihood that we will be seeing large
amounts of gatewaying to BEEP or PRIM. I have my doubts.

> multiplexing schemes. If you really need this SCTP would seem an

I'm primarily concerned about TLS, as setting up those sessions is
fairly expensive. I agree that multiplexing is a secondary issue (that's
why it's a *, not a +). But we seem to need it, even if there are
sometimes better mechanisms around. I'm not holding my breath until
every OS and end system supports SCTP.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Sep 2001 10:57:47 -0500

> multiplexing schemes. If you really need this SCTP would seem an

Why is this sort of multiplexing any different than that used for SIP 
devices, where they accept all sip traffic on 5060, and use the 
request-URI call-leg info to demux between various destinations, 
transactions, call-legs, etc?

If we have a pair of hypothetical IM session relays (assume cpim over 
tcp for the sake of argument), would you expect them to have a separate 
TCP connection for each active session between them?

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 10 Sep 2001 12:26:56 -0400

Ben, 

> TCP connection for each active session between them?
Depends on whether you care about head-of-line blocking or care whether
all your sessions are coupled in terms of TCP congestion adaptation
behavior. Some environments don't care about either and hence would not
have a problem with straightforward TCP connection multiplexing.

One of the nice things about SIP as a session establishment protocol is
that the transport mechanisms SIP uses are pretty much decoupled from
the rendezvous and transaction semantics SIP itself provides. In the
case of end-to-end "session based" IM it isn't clear this independence
is either needed or desired. If I didn't want independent session flows,
I wouldn't bother with session-mode IM in the first place and I'd just
do "paging mode".

It seems that your world model always has "IM session relays" and if you
are going to have such middleboxes between the users then it isn't clear
that you're doing "session based IM" in the first place.

Dave.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Sep 2001 11:46:48 -0500

> that you're doing "session based IM" in the first place.

I'm sorry I gave that impression, as it is not my world view at all. I 
merely chose the example of relays as a situation where you would be 
likely to have many sessions crossing the same pair of devices. If we 
could get away with saying all explicit IM sessions are point-to-point, 
I would be very happy. However, a number of participants have indicated 
a need to be able to insert proxies.

If we could get away with saying that if you need intermediaries, just 
use the page model, life would be much simpler. I am unable to fathom 
the wg consensus on that question from the list discussion.