Re: Rough sketch for an I-D (a successor of RFC 3023)

Chris Lilley a écrit  :
> On Wednesday, October 29, 2003, 5:24:57 PM, MURATA wrote:
> MM> - the MIME canonical form with short lines delimited by CR-LF, making
> MM>   UTF-16 and UTF-32 impossible
> 
> MM> - Casual users will be embarrassed if XML is displayed as text, while
> MM>   experts can certainly save and then browse XML documents.
> 
> MM> - Worries that the absence of the charset parameter of
> MM>   text/xml and text/*+xml is particularly harmful, since the
> MM>   default of that parameter is US-ASCII
> 
> Yes, that is particularly harmful. If MIME headers are given
> precedence and treated as authoritative, it makes every text/xml
> document that uses any characters outside ASCII be not well formed.

Yes, harmful and, IMHO, the main reason for deprecating text/xml and 
friends.  I'm just wondering if it wouldn't be possible to remove the 
cause instead of the effect: changing the default charset from US-ASCII 
to look-inside-the-doc, like it currently is for application/xml.

Would it be possible for 3023bis to say that?  It certainly is the case 
already for text/html, in effect if not in the specs.  Downsides?

The other arguments are not really strong, IMHO.  In fact the second one 
is more a statement that we wouldn't lose big by deprecating text/xml, 
not an argument *for* deprecating it.


> Firstly, the charset parameter and the xml encoding declaration should
> never differ, because otherwise the document is only well formed in
> transit and not when processed on the server or when saved to the
> client.

Clients should be explicitly encouraged to fix the encoding declaration 
when saving locally.

-- 
François

Received on Thursday, 30 October 2003 20:37:55 UTC