W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: review of content type rules by IETF/HTTP community

From: Sander Tekelenburg <st@isoc.nl>
Date: Tue, 21 Aug 2007 22:04:26 +0200
Message-Id: <p0624060ec2f0e3dd9e05@[192.168.0.101]>
To: public-html@w3.org

At 18:23 +0200 UTC, on 2007-08-21, Leif Halvard Silli wrote:

> 2007-08-21 17:09:58 +0200 Sander Tekelenburg:

[...]

> Currently the extension method doesn't work out of the box. But it should
>be relatively easy for browsers to start reading charset suffixes.

FWIW, iCab already does. (And the file name's charset info overrides the
document's meta http-equiv's charset value.)

[...]

> this just a help. If the charset is specified inside the file but not in
>the filename, then the browsers will use that charset instead - as they
>allready do.

I'm less sure now that I understand what exactly you propose. Do I understand
correctly that you mean that the charset info in the file name overrides both
@charset and the HTTP Content-Type charset value?

I'll grant you that, despite my aversion of file name extensions[*], it might
indeed be an option in the sense of providing a new mechanism. But Ian's 5th
point, raised in
<http://www.w3.org/mid/Pine.LNX.4.64.0708202003070.8981@dhalsim.dreamhost.com>,
remains, doesn't it?


[*] File name extensions are even less rich than MIME types. Is file.mov an
audio/mp3, or video/mpeg, or audio.ogg?


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>
Received on Tuesday, 21 August 2007 20:08:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:04 GMT