- From: Alan Barrett/DUB/Lotus <Alan_Barrett/DUB/Lotus.LOTUSINT@crd.lotus.com>
- Date: 4 Dec 96 16:00:13 EST
- To: www-international <www-international@w3.org>
- Cc: bobj <bobj@netscape.com>, wjs <wjs@netscape.com>, Chris Lilley <Chris.Lilley@sophia.inria.fr>, erik <erik@netscape.com>, Ed Batutis/CAM /Lotus <Ed_Batutis/CAM/Lotus@crd.lotus.com>
I would like to get agreement on a definite proposal of how WWW browser vendors should request a server to send UTF-8. Browser vendors are not keen to send a very long list of character sets accepted due to the overhead. So I propose that the browser vendors pick one of the following... (1) If the user, though the UI, says they want to "Request Multi-Lingual Documents" then the browser should send:- Accept-Charset:UTF-8;q=1,* However, I am worried that the Accept-Charset may not take a "*" wildcard parameter. Does anyone know? (2) This could be extended to include other charsets that the browser knows it can process efficiently. E.g. if the browser is a Japanese localisation or the user has chosen a Japanese Accept-Language then ShiftJIS could be included after UTF-8 but with a lower q value. The browser could use Accepr-Charset to request those Charsets that it can process most efficiently for each of its Accept-Languages. What do people think about this suggestion? Will it work for servers? I am really keen to give servers a chance to return UTF-8. How do servers today return UTF-8 when Accept-Charset is not generally being sent to them? Alan.
Received on Wednesday, 4 December 1996 11:00:20 UTC