ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Draft for compressing SMTP streams

2016-08-17 01:07:00
On 8/16/2016 3:37 PM, John Levine wrote:
I see that the draft has recently expired.  Are there any news about it?
No.  If there are people who would actually implement it, it's easy
enough to send in a new rev.

In case a -01 version is scheduled, I would like to point out a fairly
recent updated draft regarding the COMPRESS extension for NNTP:
     https://tools.ietf.org/html/draft-murchison-nntp-compress-05
I've looked at it, being one of the 14 people in the world who still
runs a news server.  Despite the superficial syntactic similarities,
SMTP and NNTP are not all that similar.  Most notably, SMTP traffic is
very asymmetric, with only tiny amounts from server to client, and
potentially large messages from client to server.  NNTP can go either
way.

    o  Is it worth making provision for multiple compression schemes?
       After 20 years, there still isn't anything much better than
       DEFLATE and zlib.

=> COMPRESS for IMAP permits to use other compression schemes.  We also
permit that for NNTP.  Better foresee future better algorithms from the
start.
Does anyone actually use other compression algorithms?  Options that
nobody actually uses are about the best way to create hard to diagnose
incompatibilities.

LZMA and LZMA2 (container for both uncompressed data and multiple runs of LZMA data) are strong general-purpose compression algorithms. They are considered better than bzip2 for the same computational overhead, and can take advantage of multicore/multithreaded processing. AFAIK the compression family is also free.

In crypto, a new algorithm or protocol is invented, and then vetted, and then...people don't implement it (widely) except to fulfill some arcane government requirements. Then someone figures out how to break the old algorithm and everybody jumps onto the new bandwagon because "the sky is falling!"

This cycle doesn't happen so much with general-purpose compression algorithms. The driver for adopting new compression schemes seems to be tied more to the utility of the container format that uses the scheme. (See, e.g., LZW and GIF.)

Regards,

Sean


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp