From: Mark Crispin <MRC(_at_)panda(_dot_)com>
Sender: Mark Crispin <mrc(_at_)ikkoku-kan(_dot_)panda(_dot_)com>
Subject: re: binary transport vs 8bit character transport revisited
I have to play devils advocate and add the opposite view. For the
record I would be against "banning" 8-bit character oriented transport,
because it should always be a subset of perhaps the larger solution.
For the record, I'm against 8-bit character oriented transport too, on the
grounds that:
. it is going to be a lot of work to get things interoperable with extant
7-bit software
Making 7-bit software "8-bit clean" is a major goal of most vendors
(i.e see X/Open and POSIX). It is mostly done. Doing so is probably
easier than making software cognitive of ISO 2022 escape sequences and
announcement mechanisms. Most OS's I know of are 8-bit clean now.
. it is West-Euro-centric
Rubbish. Fixing some code that allows only single byte 7-bit codes will
apply equally to the processing of any multi-octet character set (such
as Japanese JIS X0208). Encoding of Japanese can be done with two bytes of
8-bits fully encoded.
. it does not solve the general problem of international character sets
I agree, but it is the stepping stone (something functional vs nothing).
. it merely includes Western Europeans in the privileged class of those who
don't have to worry about the problem of international characters.
Nonsense. It could be applied within enclaves of usage. Chances are that
language
(hence characters of that language) will not escape outside enclaves of usage.
We just need the enclave rules defined.
The first reason is the technical reason; the others are moral reasons.
Unlike some, I see nothing magic in 8-bit datums as opposed to 7-bit,
36-bit,
9-bit, 14-bit, 15-bit, etc. I don't think the limited benefits of 8-bit
transport are worth the cost.
Similarly, I see nothing magic in 7-bit, shift state, stateful encodings. At
the end of the day (functionality on the desktop), banning 8-bit transports
would
not really help.
Glenn.