On Mon June 27 2005 10:58, ned+ietf-822(_at_)mrochek(_dot_)com wrote:
(1) Put some sort of "escape" label in the CTE field saying that
content-compression needs to be looked at.
(2) Bump the MIME-Version value to 2.0.
Changing C-T-E semantics itself would probably warrant changing the
version.
I'm not convinced that 2.0 is the next step (as opposed to 1.1 for
example).
is fundamental: An existing, standards-compliant client seees this and thinks
all it has to do is undo the base64 encoding and a bunch of text will pop out.
But when it actually does this aa pile of binary goo appears instead. The
resulting mess won't make users very happy even if clients handle it well, and
the odds are good they won't.
True.
Now, many folks believe bumping the MIME version is not possible. I'm
personally not convinced of that, but I do think it would be hugely difficult.
Bumping it just to get a compression field added strikes me as way too
much trouble for way too little gain, so (2), while technically possible,
is a practical nonstarter IMO.
Another change-C-T-E method (again, probably warranting a version change)
would be to change the syntax to permit a list of keywords, so e.g. one
could have
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: deflate
Content-Transfer-Encoding: deflate, base64
etc.
Embedding compression information in the CTE is, OTOH, entirely doable. And
not only was this understood back when MIME was first standardized, the
reason we didn't define content-compression or something similar is exactly
because this possibility existed and there was no real need for
content-compression.
Of course this leaves open exactly what compression/encoding pairs
need to be defined for use as CTEs. As you say, there are potentially
five of them, but I only see three that are genuinely useful:
binary-8bit
deflate-8bit
deflate-base64
deflate-binary
Of these I see little value in the last, but the others all make good sense.
Compression alone may be useful for transmitting large, sparse binary
files efficiently (e.g. files containing long runs of NUL octets). Of
course, that requires binary transport (e.g. ftp via message/external-body
or SMTP BINARYMIME).
However, I'm still not seeing the sort of community interest that's really
needed to get this off the ground. (In fact I'm see pretty much the opposite.)
There are disadvantages to all of the approaches. For adding encodings,
the primary disadvantage is:
o add 3 encodings per compression scheme (suppose somebody comes up with
a scheme better than deflate)
The alternative ideas address that issue. Push here, something else
pops out there.
A binary-to-8bit encoding scheme would work with SMTP 8BITMIME where
available even if BINARYMIME is not supported, and with other protocols
(IMAP, NNTP) which support 8bit but not binary content transfer. That
may have some use independent of the compression issue, so maybe that
could be standardized now, deferring the compression issue until there
is interest in it.