On Jun 28 2005, Bruce Lilly wrote:
On Mon June 27 2005 21:00, Laird Breyer wrote:
On Jun 27 2005, Bruce Lilly wrote:
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.
1. the bottleneck might be elsewhere, known to the originator, but
unknown to the network operator
2. That still implies 3749 support at the operator's side
3. it assumes that the end user knows enough to/can/will install
TLS support including the 3749 extension
These are pretty standard objections, which apply to software updates,
whether for TLS support or MIME/CTE. They don't serve as a strong
differentiator in favour of either approach.
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?
See RFC 1123 section 5.3.8.
Seems a little outdated ;-)
I'm not convinced that it is the job of the message format to make
storage easier or smaller.
We're talking about MIME, not the Message Format. MIME does a number
of things to work around transport issues. A side-effect of some of those
(notably the two non-identity encodings) is a substantial increase in
message size. Additional encodings that do not substantially increase
message size would be welcome. If they can decrease message size, so
much the better.
I accept that, but we are on the 822 list. It's still important to identify
whether and how changes to MIME can affect email.
(snip accepted points)
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 binary data, base64 encoding uses a 3:4 encoding with insertion of
a CRLF pair after at most every 76 octets of output. That's an expansion
factor of 4 / 3 * 78 / 76 or 26:19 or about a 37% (minimum) increase in
size. For binary data, quoted-printable typically expands data by a much
greater factor; quoted-printable should probably be viewed as an ISO-8859
text 8bit-to-7bit encoding.
Yes, I understand that, I'm just asking for scenarios to get an idea of
whether the cost and complexity of introducing CTEs is outweighed by
substantial benefits.
A mere 37% space saving doesn't seem worth it to me if it comes
at the cost of human readability and brittleness (change 1 byte in a
compressed stream and you can generally throw the whole thing away -
not so with text).
Even if you're transferring say an MPEG video stream,
there are key frames which allow small random corruptions to be ignored.
But compress the video, and you can throw it away if there's a corruption.
For example, there's the scenario of sending a message containing
a huge binary attachment.
For example a spreadsheet in application/vnd.ms-excel format. An order
of magnitude size reduction is typically possible via compression. I
have just such a spreadsheet; it is 428544 octets in native form and
69674 octets in OpenOffice.org (compressed) .sxc format.
That's a bad example. The Excel format is a binary serialized object format
unlike the XML OpenOffice.org format, so you've done a lossy conversion.
Compress the original spreadsheet, since that's what the CTE would do.
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.
You are assuming that:
1. the sender has a way to store the file such that it can be retrieved
by others w/o corruption
2. that bandwidth from the sender to the hypothetical storage place
isn't an issue
3. that size isn't an issue at the hypothetical storage place
4. that all recipients are able to retrieve files by the same hypothetical
method
5. that bandwidth at each recipient's side is not an issue
6. that such an arrangement is agreeable to the sender and all recipients
Look, my main objection is that there are ways to deal with some of
these issues in transparent ways.
For example, compressed filesystems solve this same storage space
issue more efficiently at the system level, and without the need to
introduce CTE handling logic in applications. Files can't be
substantially compressed twice, so having both a CTE and a compressed
filesystem wouldn't substantially increase capacity.
The bandwidth issue can be addressed transparently with TLS/SSL, or
Apache/mod_gzip, etc. for any number of current applications.
Of course, all these transparent ways must be implemented and deployed
just the same, but what is the serious long term benefit in making MIME
carry CTEs? Every MIME aware application will have to be adapted to
read those new encodings.
--
Laird Breyer.