Requesting a revision of RFC3023

Tim Bray <[email protected]> Tue, 16 Sep 2003 10:50:11 -0700
Newsgroups gmane.ietf.xml-mime
Message-ID <[email protected]>
[Some of you will get this twice, sorry; Larry Masinter pointed out that 
my initial choice of destinations was poor.  I slightly revised the note 
to provide more context.]

The W3C TAG (http://www.w3.org/2001/tag/) has an open issue about proper 
handling of MIME headers, with a draft in progress "Client Handling of 
MIME Headers" (http://www.w3.org/2001/tag/doc/mime-respect.html); the 
draft finds some fault with the contents of RFC3023.

I took an action item to ask about the chances of revising what 3023 
says about the charset parameter; while I'm not sure, I suspect that 
there may actually be some level of consensus about the desirable changes:

1. Deprecate text/* for anything that's in XML.  That's because it 
forces the provider to provide a charset header, because in its absence 
the receiver is required to assume either ASCII or 8859 depending on the 
context, which has a very high probability of being wrong, which is 
irritating because if there were no charset header the client would be 
certain of either getting it right or failing deterministically.  And 
forcing the server to provide a charset= is wrong; see the next point.

2. Deprecate the charset parameter for application/xml and 
application/*+xml.  I think that Roy Fielding would like to go far as to 
simply outlaw it; I'd be fine with that too.  The reason is that the 
client is almost certain to get it right, and will fail 
deterministically if it doesn't.  For the server, on the other hand, 
this is easy to get wrong, particularly with the introduction of various 
kinds of filters in modern web servers.  And since the Web architecture 
and the XML spec both say that the server's claim has to be taken as 
authoritative, this is really highly dysfunctional.  At the very least, 
it should be made clear that nobody sending a media-type should send a 
charset for an XML media-type unless it REALLY REALLY KNOWS what it's 
sending, and in that case should consider not sending it anyhow.

Is there any chance we could do this?  It's going to be kind of 
embarrassing for TAG findings and the Webarch doc to be saying "don't do 
what this RFC says".
-- 
Cheers, Tim Bray
         (ongoing fragmented essay: http://www.tbray.org/ongoing/)