Re: SVG12: charset parameter for image/svg+xml

Chris Lilley wrote:
> On the contrary! The +xml convention clearly indicates, for an unknown
> media type, that it is xml; thus, that an XML processor should be used;
> which will correctly determine the encoding from the xml encoding
> declaration or lack therof.

I think the concern was about what happens when someone sends the 
following HTTP header:

   Content-Type:  image/svg+xml; charset=iso-8859-1

combined with an XML document that has no encoding declaration (so 
defaulting to UTF-8).

Now per the type registration for "image/svg+xml", the above 
Content-Type header is invalid, right?  So what's a UA to do?  What 
encoding to use?  Using UTF-8 means hardcoding knowledge about the fact 
that image/svg+xml, unlike most other character-based types used today, 
doesn't have a charset parameter.

> No, they would not. RFC 3023 already allows the charset to be omitted,
> and gives rules to follow for this case. SVG follows those rules, as the
> registration document makes plain.

The problems arise when there IS a charset parameter.  I don't think 
anyone ever claimed there is a problem when the charset parameter is 
omitted.

>    In general, a representation provider SHOULD NOT specify the
>    character encoding for XML data in protocol headers since the data is
>    self-describing

Given that this is a not a MUST NOT, people will continue to do this in 
some cases (particularly as some web servers automatically tack on a 
"charset" parameter to Content-Type headers).

-Boris

Received on Monday, 1 November 2004 20:46:24 UTC