If another compression, say, bzip, is introduced, how will I know if software X will support it? I can generally know if software X supports media-types. But introducing new compression types within the same media-type sounds hard to ask. paul Le 3 sept. 2010 à 22:15, Ron Wilson a écrit :
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@alvestrand.no> wrote:
Date: Thu, 02 Sep 2010 14:03:51 +0100 From: Alexey Melnikov <alexey.melnikov@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.