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