Re: Additional comments on image/svg+xml
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.
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.
On 03.09.2010 22:15, Ron Wilson wrote:
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. ...
IHMO: if this was a "custom", binary media type, then yes, you could define whatever you want. Although I still don't think it would be a good idea. However, this is a +xml type, and it needs to be compatible with what RFC 3023 says. Best regards, Julian
On Fri, Sep 3, 2010 at 5:36 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
IHMO: if this was a "custom", binary media type, then yes, you could define whatever you want. Although I still don't think it would be a good idea.
However, this is a +xml type, and it needs to be compatible with what RFC 3023 says.
Then I would favor requiring that XML based content that is compressed carry the type and extension of the container and let the opener-of-the-container determine how to process the contents, rather than promote the proliferation of multiple types and extensions for what is ultimately the same content.
participants (3)
-
Julian Reschke -
Paul Libbrecht -
Ron Wilson