In <20050629070218(_dot_)GA30094(_at_)ender> Laird Breyer
<laird(_at_)lbreyer(_dot_)com> writes:
If it really has to be tried out, wouldn't a few content types
make more sense to test the waters? A CTE which replaces them can
always be defined some years later, and in the meantime it doesn't
force all standards compliant software to implement a decompressor.
How about:
Content-Type: application/compressed; protocol=gzip;
uncompressed-type="image/jpeg" (; and all parameters of the
uncompressed type allowed here)
Content-Type: application/compressed; protocol=gzip;
uncompressed-type="text/html"; charset=iso-8859-1
Repeating for the Nth time: Media types are supposed to be used to identify
types of media, not general compression schemes or other stuff. Section 2.2.1
of RFC 2048 is very clear about this, and this requirement remains unchanged in
section 4.1 of draft-freed-media-type-reg-04.txt. As such, any attempt to
register such a media type will be immediately rejected.
If you want to play around with general compression schemes and MIME in a
standards-compliant way, nothing prevents you from using x-gzip or whatever
as a CTE.
Ned