On Friday 28 February 2003 20:03, Bruce Lilly wrote:
<snip>
A UA issue:
Currently, with QP and Base64, binary content can simply
be Base64 encoded (QP isn't terribly effective for binary
content, nor is Base64 terribly useful for text which has
a few 8-bit octets). So the UA can pretty much do the
right thing without user interaction or user
sophistication.
base64 remains the safe bet even with deflate-* added...
Of course, a knowledgable user could
apply compression before attaching. Unfortunately in
practice there exists a large variety of compression
and/or packaging mechanisms (e.g. just the other day I
recieved an attachment in "Stuffit" format, and I had
to track down a decoder for that).
With a larger choice for binary attachment encodings, things
get a bit more complicated. The UA can't necessarily
determine whether the MTA will support 8BITMIME (the user
may be off-line).
The the UA should record the capabilities of the SMTP server for that
account or default to a 7bit domain CTE.
Yet a choice must be made among the
available encodings. Negotiation along the lines
of RFC 3297 might be useful. Simply asking the user to
choose probably isn't practical, as the vast majority of
users have little technical sophistication.
However, the UA could presumably choose between a straight
base64 and deflate-base64 based on how well the binary
content compresses.
<snip>
If a MUA wants to automatically determine the CTE to use (without always
using base64), it has to do character frequency counting (either by
hand or using prior knowledge based on the mime type). If you do that,
you can easily extend that to calculate the entropy-per-char of the
data and base your choice of using deflate-* or not on that, although
it's probably not worth it anyway, since deflate has a fairly low
overhead for already compressed data.
Marc
--
Military justice is to justice what military music is to music.
-- Groucho Marx
pgpioU54U9OjU.pgp
Description: signature