Subject: Re: [lemonade] COMPRESS Thoughts

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 1 Jun 2006 11:44:52 +0200

Dave Cridland writes:
> As I say, though, actually compressing does reduce the octet count, 
> and compressed blocks don't have the overhead - I'm not clear if a 
> new block needs to be started for a Z_SYNC_FLUSH or not, in fact. 
> I've never seen compression actually expand data.

I have, for exactly one IMAP command. I think it was the very first 
"select inbox" after "compress deflate". All subsequent commands 
compress, and most compress well.

Remember that most IMAP clients tend to send the same few commands again 
and again with only numbers changing. For example, one of the MUAs my 
wife uses sends "<letter><three digits> FETCH <number>:<number> (UID 
FLAGS INTERNALDATE FC822.SIZE BODY.PEEK[HEADER.FIELDS (DATE FROM 
SUBJECT TO CC MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION 
IN-REPLY-TO REPLY-TO LINES LIST-POST X-LABEL)])" every time it receives 
an EXISTS. After compression, that 200-byte command is a ten-byte 
command. After compression and TLS, it's a 16-byte one (or 17?).

I bet Polymer constructs its IMAP commands cleverly and uses short tags, 
which gives more variety, and that's why you see only 50% compression 
on the upstream.

Arnt

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

---

From: Dave Cridland <[email-masked]>
Date: Thu, 01 Jun 2006 13:26:05 +0100

On Thu Jun 01 10:44:52 2006, Arnt Gulbrandsen wrote:
> Dave Cridland writes:
>> As I say, though, actually compressing does reduce the octet 
>> count, and compressed blocks don't have the overhead - I'm not 
>> clear if a new block needs to be started for a Z_SYNC_FLUSH or 
>> not, in fact. I've never seen compression actually expand data.
> 
Ah, I don't see that, because I send "compress deflate" prior to an 
"authenticate digest-md5" using the SASL-IR extension, meaning 
there's base64 encoded data, which usually compresses.

> I bet Polymer constructs its IMAP commands cleverly and uses short 
> tags, which gives more variety, and that's why you see only 50% 
> compression on the upstream.

Well, I'm really hoping that any client intending to be deployed over 
low-bandwidth (or usage-billed) links would do at least the same.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade