W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 01 Nov 2004 14:46:15 -0600
Message-ID: <4186A097.4060805@mit.edu>
To: Chris Lilley <chris@w3.org>
CC: www-svg@w3.org, ietf-types@iana.org

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 

>    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).

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

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:01 UTC