Why should 2 extensions be needed to indicate the presence or absence
of compression? Even in the absence of a transfer encoding header,
container formats like GZIP are readily recognizable by reading the
first several bytes and the appropriate container handler can be
invoked as needed. One example of an application that does this is
Dia. (I think another example is the GIF format. As I recall, the
difference between a compressed and uncompressed GIF image is the
presence or absence of LZW compression, which is really just another
container format.)
If we need a 2nd extension and type for the GZIP'ed version of a type,
then we will need a 3rd/4th/etc extension and type when additional
container formats are introduced.
On Fri, Sep 3, 2010 at 6:00 AM, <ietf-types-request(a)alvestrand.no> wrote:
> Date: Thu, 02 Sep 2010 14:03:51 +0100
> From: Alexey Melnikov <alexey.melnikov(a)isode.com>
>
> MIME experts think that using +xml for gzipped material is a really bad
> idea, and that having two extensions for one MIME type, with different
> semantics, and with a dependency on transfer-encoding, is a bad idea.
> This looks like MIME type sniffing and MIME media types were explicitly
> designed to avoid this.
>
> The cleanest way to fix this (without having a long debate about what is
> correct and what is not according to MIME spec) is to have 2 separate
> MIME type registrations (one for XML and one for gzipped version), each
> using own file extension.
