Subject: RE: [lemonade] Compression: TLS or Application-layer

From: [email-masked]
Date: Tue, 28 Sep 2004 01:27:10 -0500

I'm glad you brought this up Eric.  I think this is needed for low
bandwidth terminals.  Computational power of terminals is growing faster
than network bandwidth at the current time, so I feel this is a key
technology.

I think TLS compression is fine, but for consumer level systems which
will not be enabling IMAPS (simply because they don't know what it is) I
think we will need application level compression (like P-IMAPs GZIP).

I agree with Arnt that stream compression is better than individual
message compression, but we may be able to define both.

Corby

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext Arnt Gulbrandsen
> Sent: Monday, September 27, 2004 12:52 PM
> To: [email-masked]
> Subject: Re: [lemonade] Compression: TLS or Application-layer
> 
> Eric Burger writes:
> > Does anyone have DATA on the computational complexity, resulting
> > compression ratio, and I/O impact (e.g., must scan entire document
> > vs. compress on x Bytes)?
> 
> I ran a few IMAP connection logs through something much like P-IMAP
and
> something much like TLS compression last year, when I wrote the
> draft=compress.
> 
> Not sure whether I still have the data. Can look tomorrow in the
office.
> The conclusions are simple, anyway: synonyms (e.g. "F" for "FETCH")
are
> meaningless, compressing the stream as it goes is good, compressing
> individual fetch responses less good.
> 
> Arnt
> 
> _______________________________________________
> lemonade mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/lemonade

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 28 Sep 2004 15:22:52 +0200

[email-masked] writes:
> Just because we can do something doesn't mean that we should.

Let's _please_ not. More code to debug is a pain. More optional bits and 
pieces in the protocol harm interoperation (unless both client and 
server are tested to interoperate in every possible configuration, ha 
ha ha ha *cough* *cough*).

Arnt