That would be in SMTP, POP and IMAP, right? The later two are important
to end users because it will save them disk space and download time.
I worry about IMAP because I think I remember a long time ago Crispin
saying it was hard to do binary with the extent IMAP protocol syntax.
I like the transport layer because the compression can be negotiated so
you don't have the mailcap / deployment problem. Further compression may
be of interest on small devices communicating over slow links (e.g.
wireless). On some of these devices memory is limited enough that some
algorithms have to have their hufman or other encoding tables throttled.
For example gzip uses a 32Kb table, and getting an implementation onto a
Palm Pilot would not be straight forward. Transport layer compression
would allow the encoding table size to be negotiated.
I also like the ability to avoid the 15% or so overhead needed to send ASCII.
I don't have hard numbers handy, but I have done some tests compressing
mail messages, even small ones and concluded it was well worth it. Also
I'm not sure that link layer compression can come close to the
effectiveness of doint it at higher layers, even for general purpose
compression algorithms. Link layer compression schemes cannot operate on
more than a few hundred bytes at a time or they will introduce latency
that is highly undesirable and unexpected.
Perhaps the big downside to transport layer compression is that it has to
be redone with each transport session there by sucking up lots of cycles
on the Internet's mail servers (that might be better used to crack DES:-).
LL
On 10 Sep 1998, John C Klensin wrote:
....
client: EHLO my.dom.ain
server: 250-BDAT-LZmm
s: 250 EXPN
[...]
client: BDAT LZmm NNN
s: 354 expecting NNN octets
c: [...data...]
s: 250 Received ok
Now, like Steve, I'm not completely convinced any of this is
worth it. But, if one is going to do it, then it may be worth
the slight extra trouble (and perhaps easier deployment) to do
it at transport and get all of the gains possible.
john