ietf-822
[Top] [All Lists]

Re: MIME compression mechanism

1994-10-13 22:49:18
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.


<Prev in Thread] Current Thread [Next in Thread>