W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: Charsets revisited

From: Glenn Adams <glenn@stonehand.com>
Date: Thu, 25 Jan 96 12:08:53 -0500
Message-Id: <9601251708.AA21707@trubetzkoy.stonehand.com>
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.

Glenn Adams
Received on Thursday, 25 January 1996 09:14:39 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:16 UTC