- 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