> In <20050629070218.GA30094@ender> Laird Breyer <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.