On Jun 27 2005, Bruce Lilly wrote:
On Sun June 26 2005 23:51, Laird Breyer wrote:
Since support for compression is already built into the TLS protocol
by RFC 3749, the benefit in lower bandwidth requirements and faster
transfer can be achieved today as long as both the server and client use
this feature.
That's a big "if". Obviously, that's only hop-by-hop, and it doesn't
apply it TLS isn't available, or with TLS implementations that do not
support the RFC 3749 extension.
That's correct, but surely it's the way it should be: if some network
admin wants to allow faster transfers to his users, then he'll set up
the software. Given the general fuss about authentication and
security of email services, TLS is already likely to be used or on the
list of things to be used.
Such compression cannot work around e.g. SMTP message size limits as
the message would be stored in uncompressed form.
Which SMTP size limits are those? I had a quick check on my copy
of RFC 2821 (page 55) and I don't see any hard limits on the total
message size. There's the SIZE extension and there are standards for
splitting a message into pieces.
I'm not convinced that it is the job of the message format to make
storage easier or smaller. In fact, the best compression can only be achieved
by the final destination system, because it can combine the characteristics
of all received messages in optimal ways.
On the other hand, the message sender is already free to compress his
attachments any way desired,
Indicating the fact of compression and the method by...? (w/o obscuring
the nature of the media type that is compressed)
What's wrong with an application/gzip (or similar) attachment and a
Content-Description field which tells the user what's inside?
There are two distinct issues at work:
1. encoding binary data to fit into 8bit (as opposed to 7bit) transport
can be done in a more space-efficient manner than is possible with
binary-to-7bit encoding
2. compression for size reduction of stored/transmitted content
I'd like to understand these points better. What kind of space saving
scenario do you have in mind?
For example, there's the scenario of sending a message containing
a huge binary attachment. Arguably in that case, the sender is misusing
email as a file transfer facility, and should only send instructions on
how to retrieve the file separately.
Another scenario is the case of an SMTP agent being overwhelmed by
large message numbers such as spam. In that case, a compressed
attachment format would make a difference, but it relies on the sending
parties actually using the compressed transfer encoding as intended.
--
Laird Breyer.