Re: image/svg+xml, was: Feedback on Internet Media Types and the Web

On 18.11.2010 20:01, Henry S. Thompson wrote:
> ...
>> That's no problem.
>>
>> However it *is* a problem to claim that .svgz files have the type
>> "image/svg+xml". They don't. Feed them into a recipient that expects
>> XML and see it fail.
>
> 'claim'?  Claim how?  Who has claimed this?  How might someone claim
> this in any substantive way, except by failing to include the above
> Content-Encoding header in a message containing a gzipped SVG
> document. . .

The media type registration claims it. If that's not the intent, can we 
please clarify it?

> OK, I've now followed the link [1] in your original message, and it
> seems very odd to me.  The passage Mark Nottingham quotes, modulo the
> correction of Content-Transfer-Encoding to Content-Encoding, seems
> entirely satisfactory to me.  What is the Content-Encoding header [2]
> _for_, if not precisely for this case:
>
>   "The Content-Encoding entity-header field is used as a modifier to
>    the media-type. When present, its value indicates what additional
>    content codings have been applied to the entity-body, and thus what
>    decoding mechanisms must be applied in order to obtain the
>    media-type referenced by the Content-Type header field."

Yes. That is true for *any* media type, so it's totally unclear why it 
needs to be repeated.

The registration for SVH however says that it's ok to sniff:

"In addition, gzip compressed content is readily recognised by the
initial byte sequence as described in [RFC1952] section 2.3.1."

That's at least how I read it.


> I've included Mark and Alexey in this conversation --- Alexey, I think
> we particularly need to hear from you about what is wrong with a
> message with the headers quoted above.
> ...

I recommend that we have this conversation on the media types mailing list.


Best regards, Julian

Received on Thursday, 18 November 2010 19:13:04 UTC