Subject: Submit Direction (was RE: [lemonade] COMPRESS Thoughts)

From: "Burger, Eric" <[email-masked]>
Date: Tue, 13 Jun 2006 05:00:55 -0400

Mea Culpa: I used poor language when attempting to describe the
asymmetrical nature of compression.  Re-reading what I wrote, and the
subsequent thread, it is apparent that what I wrote made it sound like
we were ONLY going to have compression in the Server->Client direction,
and we would NOT have compression in the Client->Server direction.

Thing 1: That was not the consensus.  The consensus was there could be
situations where you would want compression all the time in both
directions (the typical case); there could be situations where you would
want compression only Server->Client but not Client->Server; for that
matter, there theoretically could be situations where you would want
compression only Client->Server (although I cannot think of any).  The
point I was trying to make is that we needed to handle compression in
one direction, AS WELL AS compression in both directions.

Thing 2: The entire discussion revolved around IMAP.  As has been
pointed out on the list, compression would be an incredibly useful
feature for SUBMIT.

Thing 3: Compression on SUBMIT does not depend on compression for IMAP.

Thing 4: Lemonade does not strictly depend on compression to get
published.

Thing 5: I don't want to expand our work before we finish our committed
work.

Given these Things, I would offer we work out Compression for IMAP
first.  We need data collection (what resources get saved, what
resources get spent, is CPU really that much more expensive than Radio
[I thought not :->], etc.).  Once we finish Compression for IMAP, doing
a Compression for SUBMIT should be a trivial exercise for the reader.

OK?

On Wed May 31 20:29:26 2006, Burger, Eric wrote:
[snip]
> (2) Consensus that compression is directional, i.e., downstream
> compressed, upstream uncompressed.  This is because IMAP upstream
> commands may be real short (meaning compression actually adds CPU 
> *and* bits used), while content may be real long.
[snip]

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade