Such a mechanism might be useful for other types *besides* audio,
video, and image. However, it would be difficult to gain support
for a compressed content-trasnfer-encoding, because a body part
encoded with a unknown encoding would be unreadable by every
existing MIME reader.
Please discuss spec and implementation issue separately. All MIME
interfaces can't handle compressed MIME parts now. But when such a
spec is defined, many MIME interfaces would support this mechanism.
Perhaps. But the subject has come up before, and this objecection
has always been raised when it did.
New content-transfer-encodings can be defined, but must be approved in a
standards-track RFC, which in turn requires the consensus of an IETF working
group.
By contrast, *changes* to the MIME grammar for the content-transfer-encoding
(like the one you proposed in your earlier message to combine base64 and a
compression algorithm) are probably even more difficult to acheive.
I am on record as being in favor of a "gzip" content-transfer-encoding.
The next step would be for someone to write up a specification for it,
and see if it can gain working group approval.
--
Keith Moore NETLIB development group
Computer Science Department / University of Tennessee at Knoxville
107 Ayres Hall / Knoxville TN 37996-1301
Let's stamp out the content-length header in our lifetime.