Subject: RE: [Simple] Sessions of MESSAGEs

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Aug 2001 12:55:33 -0400

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Monday, August 20, 2001 10:57 AM
> To: Peterson, Jon
> Cc: [email-masked]'
> Subject: Re: [Simple] Sessions of MESSAGEs
> 
> 
> I assume we would still keep MESSAGE for non-session messaging. After 
> writing the draft on using MESSAGE in sessions, I am probably its 
> biggest critic. I think we should abandon that effort completely.

I agree.

> 
> As far as the message stream itself, I have heard some 
> support for the 
> idea of doing pure message/cpim over TCP and TLS. Personally, this 
> sounds better the more I think about it.

Even that is wasteful, IMHO. CPIM will carry things like the From/To fields,
which are superfluous within a session.

I think there is only one sensible way to solve this problem. Rather than
starting from protocols, lets start from requirements. What do we need this
transport to do for us? From there, we can select the option which best
meets the requirements.

Here is my start:

1. reliable, sequenced delivery of messages
2. support for messages of arbitrary size, from 1 byte to megabytes (think
aimster)
3. congestion control
4. framing
5. content typing (text/html, text/plain, etc.)
6. support for e2e privacy, authentication, integrity
7. natability (i.e., can be made to work through nats without major
headaches)
8. rapid delivery (one the order of hundreds of milliseconds to a second)
9. relatively lightweight (will need to be implemented in phones and other
smaller devices)

others, anyone?

-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: Ben Campbell <[email-masked]>
Date: Mon, 20 Aug 2001 12:04:07 -0500

Do we need to select MIME type on a per-message basis, or just once per 
session?

Jonathan Rosenberg wrote:

> Even that is wasteful, IMHO. CPIM will carry things like the From/To
> fields, which are superfluous within a session.
> 
> I think there is only one sensible way to solve this problem. Rather
> than starting from protocols, lets start from requirements. What do we
> need this transport to do for us? From there, we can select the option
> which best meets the requirements.
> 
> Here is my start:
> 
> 2. support for messages of arbitrary size, from 1 byte to megabytes
> (think aimster)
> 3. congestion control
> 4. framing
> 9. relatively lightweight (will need to be implemented in phones and
> other smaller devices)
> 
> others, anyone?
> 
> -Jonathan R.
> 
> ---

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Aug 2001 13:51:48 -0400

Comments below.

	Paul Kyzivat
	Cisco Systems

Jonathan Rosenberg wrote:
> 2. support for messages of arbitrary size, from 1 byte to megabytes (think aimster)
> 3. congestion control
> 4. framing
> 7. natability (i.e., can be made to work through nats without major headaches)

10. provision for IM conferences. A primary need here is to permit a
media endpoint to act as a mixer. This in turn requires the ability to
send messages attributed to others. Encoding the messages as CPIM would
seem to provide this capability, while sending raw MIME content would
not.

> Do we need to select MIME type on a per-message basis, or just once per

I think per-message. You may want to intersperse pictures with text, or
encoded meta-messages with real text messages.

Of course, if you have a rich enough MIME type it can be good enough.
For instance, CPIM is rich enough because it can include any other type.
But that isn't really any different than selecting MIME type
per-message.