Additional comments on image/svg+xml

[Julian Reschke]

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