- From: Glenn Adams <glenn@stonehand.com>
- Date: Thu, 25 Jan 96 12:08:53 -0500
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> From: Larry Masinter <masinter@parc.xerox.com> > Date: Thu, 25 Jan 1996 08:23:02 PST > you cannot possibly mean that the *same* HTTP server will employ > 2022-jp, shift jis, euc-j, unicode-1-1 and unicode-1-1-utf7. Why not? Sure, the platform on which the server runs is unlikely to employ all these at once; however, a single server could easily recognize and interpret all of these encodings, translating them as necessary to the platform encoding. > My recommendation for the solution to this problem is that we > establish an application profile 'HTTP servers for Japanese' that > recommends that filenames in URLs be encoded as unicode-1-1-utf7 no > matter what the native file system encoding might be. I do not believe this is an acceptable solution (no matter how much I prefer using Unicode over other character sets), and that it avoids solving the real problem (charset tagging). This would mandate that all servers embed knowledge of Unicode (not necessarily a bad thing). On the other hand, a given server might want to support, say ISO-2022-JP, EUC-J, and SHIFT JIS encodings exclusivly, if, for instance, its platform character set were Shift JIS. It would still be essential to identify which of ISO-2022-JP, EUC-J, and SHIFT JIS were used in the encoding of requested URLs. Regards, Glenn Adams
Received on Thursday, 25 January 1996 09:14:39 UTC