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