home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.std.internat:885 news.admin.misc:809
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!att!allegra!alice!andrew
- From: andrew@alice.att.com (Andrew Hume)
- Newsgroups: comp.std.internat,news.admin.misc
- Subject: Re: 8-bit news
- Summary: not really
- Message-ID: <24425@alice.att.com>
- Date: 17 Dec 92 05:08:44 GMT
- Article-I.D.: alice.24425
- References: <Bz9Bw3.2I6@ra.nrl.navy.mil> <89RsVB3w165w@blues.kk.sub.org> <1glkdeINNqfr@tik.vtt.fi>
- Organization: AT&T Bell Laboratories, Murray Hill NJ
- Lines: 19
-
- In article <1glkdeINNqfr@tik.vtt.fi>, Markku.Savela@tel.vtt.fi (Markku Savela) writes:
- > In article <89RsVB3w165w@blues.kk.sub.org> kosta@blues.kk.sub.org (Kosta Kostis) writes:
- >
- > Actually we already have one ultimate character encoding system, sort
- > of. And that is ISO 2022 + registered character sets. Implementing
- > that is about the same complexity as ISO 10646, it's just different
- > encoding for the same information.
-
-
- even with a half-smiley, this is just plain bonkers. and
- juts plain untrue. i have seen a draft of a standard where a character
- set was defined by a table of 10646 values -- no one has or will
- apply for a character set escape sequence name.
-
- the bottom line is that 2022 was a barely manageable system
- that was so baroque that no one implemented save those who had to
- (mainly europeans). in the context of 7-bit transmission, it was
- a plausible technique. nowadays, it is simply bogus. let it die a
- natural death.
-