- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 01 Nov 2004 14:46:15 -0600
- 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 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