# Let me know if this is a wrong place.
I have read rfc1521 and draft-ietf-822ext-mime-imb-00.txt but I can't
find compression mechanism for MIME. As you know, picture or audio
data is too large. So, I think compression mechanism is very important
for MIME.
Both picture and audio data usually need a compression algorithm that is
fine-tuned for the type of data being compressed. A general-purpose
compression algorithm (like gzip or lzw) is usually ineffective for these
kinds of data.
In these case, it is best if the content-type defines the compression. For
instance, image/jpeg and image/gif images are already in compressed form.
Audio/basic is also compressed (in a sense) by the use of mu-law encoding to
reduce the number of bits required by each sample. One can suppose that
additional image, audio, and video types to be defined in the future will
also incorporate compression as part of the content-type itself.
If current MIME has no compressin mechanism, I'd like to suggest a
subtype -- "compression" -- for Content-Transfer-Encoding:. For
example,
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.
Keith Moore