Re: [xml-dev] xml over http - RFC 3023

[Julian Reschke <julian.reschke@gmx.de>]

David Carlisle wrote:
> No. The XML REC is very explicit that if the encoding is specified in
> both places the external specification should be used and the encoding
> declaration ignored. 
> 
> The thinking is/was that this allows proxies and mail gateways and
> things to reencode documents witout having to go in and edit the
> document, however it's a real pain because in many scenarios it is so
> much easier to get the ecoding right in the file, than it is to get it
> right on the server.

Does this happen in practice?

> xml 1.0 5th edn, ehich has just come out has made many incompatible
> changes, but it hasn't changed this, it still defers the question of
> whether external or internal encoding is authorative to the respective
> mime type registration, which is (now) 3023 which says
> 
> http://www.ietf.org/rfc/rfc3023.txt
> 
>   There are several reasons that the charset parameter is
>       authoritative.  First, some MIME processing engines do transcoding
>       of MIME bodies of the top-level media type "text" without
>       reference to any of the internal content.  Thus, it is possible
>       that some agent might change text/xml; charset="iso-2022-jp" to
>       text/xml; charset="utf-8" without modifying the encoding
>       declaration of an XML document. 

I think there's consensus that if the content-type has a charset 
parameter, it really should be used.

The problematic thing is that RFC3023 and RFC2616 specify defaults in 
case it's missing, and these defaults are even conflicting.

For RFC2616bis, the plan is not to specify a default anymore (again: 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/20>).

In general, the easiest way to avoid these issues is to use 
application/*xml, which doesn't have the problem with the defaulting.

BR, Julian