Dan Kohn wrote:
However, can you (or anyone else) comment on the interest in a 7bit
compressed CTE. I'm currently leaning toward doing only a deflate-8bit,
and not also doing a deflate-base64. If an 8BitMIME MTA needs to
downconvert for next hop delivery, it would need to implement both
unescaping of the 8bit octets and decompression. Do you envision this
as a problem?
The reason is to try to minimize the number of CTEs.
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. 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). 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. Likewise it could choose between
deflate-8bit and some encoding/line-breaking method to
convert binary content to 8bit-compatible form if such
a method were available.
The amplification factor that Marc Mutz identified could
be used as a DoS attacxk against an MTA as well as against
an end user. E.g. if somebody intended to attack an MTA
which does not support 8BITMIME, the same issues that
Marc identified will come into play, and could be further
amplified by the number of envelope recipients. If
deflate-base64 is used, that issue does not arise for the
MTAs, and users benefit by having a standard compression
method rather than a hodgepodge.
Marc's other point about possibly separating the translation
and line-breaking from deflate is also interesting. In the
case of binary content which does not compress well, that
could be used to encode the content for transfer over an
8BITMIME link, just as base64 alone (w/o the deflate
compression) could be used if 8BITMIME is known to be
unavailable.
Content-Transfer-Encoding actually specifies two nearly
independent items; an encoding and the domain of the
(possibly-encoded) content. Both of the currently
standardized encodings have a 7bit domain.
Summary: I think the ideal situation would include having
deflate-8bit, deflate-base64, and the
escaping/line-breaking method (separate from compression),
combined with support for RFC 3297 negotiation. That way
it is possible for UAs and MTAs to handle transfer
compatibly and transparently for unsophisticated users,
and the negotiation puts the onus on the sender to provide
an uncompressed alternative if the reciever or intermediate
MTA determines that deflation would exceed some size
limit.