Additional comments on image/svg+xml

[Paul Libbrecht]

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 at alvestrand.no> wrote:
>> Date: Thu, 02 Sep 2010 14:03:51 +0100
>> From: Alexey Melnikov <alexey.melnikov at 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.