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:
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
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
Does anyone actually use other compression algorithms? Options that
nobody actually uses are about the best way to create hard to diagnose
Incidentally, are you sure a separate CDAT command is the wisest
solution for SMTP (instead of a compression layer, like TLS)?
Yes, see previous discussion. The compression layer requires a
three-way coroutine system which is a lot more fragile than sending
the data through already debugged TLS connection code, and this
completely avoids the CRIME issue and its relatives.
Keep in mind that one of the advantages of a compression layer is that
you can also decide not to compress data (setting the compression level
at 0 for commands or answers that do not need being compressed). The
client may know that the contents is already compressed (jpg or zip
attachment for instance) and decide not to compress it again.
How is this different from CDAT? The client can send anything that
DEFLATE can be persuaded to produce. If you're using zlib, you call
deflateParams to tell it how to change its compression strategy and
ietf-smtp mailing list