- From: Erik van der Poel <erik@netscape.com>
- Date: Wed, 04 Dec 1996 10:03:09 -0800
- To: Alan Barrett/DUB/Lotus <Alan_Barrett/DUB/Lotus.LOTUSINT@crd.lotus.com>
- CC: www-international <www-international@w3.org>, bobj <bobj@netscape.com>, wjs <wjs@netscape.com>, Chris Lilley <Chris.Lilley@sophia.inria.fr>, Ed Batutis/CAM /Lotus <Ed_Batutis/CAM/Lotus@crd.lotus.com>
> Browser vendors are not keen to send a very long list of character sets > accepted due to the overhead. Right. This is one concern that keeps coming up over here at Netscape. At the Sevilla conference, Larry Masinter mentioned "transparent content negotiation", where it is apparently possible for the client to first indicate a willingness to negotiate, and the server could respond with a list of choices, from which the client makes a choice. This, however, requires another round-trip to the server and back, and might be even more expensive than just sending all the charsets in the first place. How about using a more compact representation of Accept-Charset. E.g. bit masks corresponding to the number in the charset registry. This would omit the "q" parameter, but I'm not sure this is needed in the Accept-Charset case anyway. (It's probably needed for Accept-Language.) > (1) If the user, though the UI, says they want to "Request Multi-Lingual > Documents" then the browser should send:- I don't think we should have UI for the Accept-Charset. Think about novice users. Will they understand it? > 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? Servers cannot send UTF-8 to clients unless they know that the client is capable of decoding it or there is a large critical mass of browsers in the installed base that is known to be capable of decoding UTF-8. Erik
Received on Wednesday, 4 December 1996 13:03:48 UTC