On Jun 8, 10:54, Bill Janssen wrote:
I think Steve's got a point here. "Content-Type:
application/compressed-tar-file; compressor=compress" would make a lot
of sense in this particular case. I'm not sure it would hold for the
more general (and I think different) case of wanting to send compressed
bodies in general.
Bill
-- End of excerpt from Bill Janssen
If we combine some of the ideas which have been discussed, a general
solution for specifying compression could be to have one new
content-transfer-encoding, and allow a parameter:
Content-Transfer-Encoding: compress64; compress-algorithm=LZ77
(LZ77 is the compression algorithm used by gzip.) We could have a default
value, if the parameter is not included.
This doesn't break existing implementations, it doesn't mix the type of
compression with the type of transfer encoding, and it provides
extensibility. Some have argued against extensibility due to the
decreased likelihood of interoperability. Yet, the MIME community may
want to change the algorithm in the future, and people may want to use
other "x-" compression schemes once they've agreed to do so. (Honesty
requires me to point out that any arbitrary transformation could be done
using an "x-" compress specification.)
It looks like we'll be moving towards specifying which content-types are
recommended, and which are registered so that people know how to name
things consistently. (I think this is an EXCELLENT idea.) We can do the
same thing with compression algorithms.
--Carlyn Lowery