From andrew@research.att.com Tue Dec 22 20:23:00 1992 Received: from research.att.com by dkuug.dk with SMTP id AA24511 (5.65c8/IDA-1.4.4j for ); Wed, 23 Dec 1992 07:40:51 +0100 Message-Id: <199212230640.AA24511@dkuug.dk> From: andrew@research.att.com Date: Wed, 23 Dec 92 01:23 EST To: i18n@dkuug.dk X-Charset: ASCII X-Char-Esc: 29 glenn (keld, i18n): i agree with essentially all the facts you present. i would disagree in two areas. the first is that whether or not it is true, the perception is that unicode/10646 is a solution for handling international character sets in computer systems. i know it isn't; you know it isn't; but lots of people don't. and it isn't helped by the tentative steps towards encoding issues (UTF-1) and a processing model (LR or RL order etc). nevertheless, i (and you and others) still need to eductae such folks and say that more or less, 10646 essentially defines codepoints. the second is the issue of system design (by and large, the stuff 10646 didn't address). certainly at the beginning, the unicode folks were quite gung-ho about this; the world was going to a 16-bit char universe with all that that implies (and for unix-style systems, that is quite a lot). for some systems, this may be a plausible view, but as i argued in my note, it isn't in the general case. i know work is going in within unicode (i said so!), but it is indicativeof the funny priorities involved that the hardest part, system integration, has had essentially no air time in either the unicode or 10646 mailing lists (except when i have complained about the lack of a model). please understand i mean this not as a criticism of the unicode or 10646 folks; its just that from the outside, no one is addressing this issue. (as i said, designing character handling libraries, although useful, is not system integration.) and i am happy with the response that we are now working on the issues of system integration; again, i just want to point out that this runs counter to the expectation of most folks ``out there''. andrew hume