- From: Brian Smith <brian@briansmith.org>
- Date: Mon, 18 Aug 2008 00:53:33 -0500
- To: "'Frank Ellermann'" <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>, <ietf-http-wg@w3.org>
Frank Ellermann wrote: > Brian Smith wrote: > JFTR, again, I think we need a clear transition strategy. > But so far we don't have it. Agreed. > > there are no features for language tagging > > Of course there are. Raw UTF-8 doesn't offer this, unless > you try the NOT RECOMMENDED obscure u+E00?? language tags. Even with RFC2231 encoding the Unicode language tagging mechanism would still be needed for mixed-language text. > > it is only suitable for short, language-neutral strings > > like (file and IRI) path fragments. > > Do you propose to remove the optional [language] element in > the draft ? It's a possibility, but some lines above you > said language tagging is essential. Language tagging is needed for a general-purpose mechanism. However, in the specific case of filenames, the UA should and will display the filename as it will be presented by the operating system. That means a Japanese user will see a Chinese-language filename using Japanese glyphs if the operating system's locale is Japanese. Similarly, AFAIK operating systems do not preserve BIDI formatting codes in filenames, so the UA would have to strip out any BIDI overrides in the filename before presenting it to the user. Language tagging and BIDI override support for Content-Disposition's filename parameter are not really necessary. > > The draft references Unicode 4.0 indirectly through RFC3629. > STD 63 is not, repeat NOT, bound to some > specific Unicode version. OK. - Brian
Received on Monday, 18 August 2008 05:54:10 UTC