Path: utzoo!attcan!uunet!snorkelwacker!usc!cs.utexas.edu!longway!std-unix
From: randall@uvaarpa.Virginia.EDU (Randall Atkinson)
Newsgroups: comp.std.unix
Subject: Re: 8859 vs. 646
Message-ID: <584@longway.TIC.COM>
Date: 20 Mar 90 18:16:20 GMT
References: <579@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: randall@uvaarpa.Virginia.EDU (Randall Atkinson)
Organization: University of Virginia, Charlottesville
Lines: 24
Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)

From: randall@uvaarpa.Virginia.EDU (Randall Atkinson)

I understand that there are many sites that currently have
terminals supporting ISO 646, but by the same token, there
are a lot more terminals that support US ASCII and a lot of
other terminals out there that are vaguely derived from US ASCII
in a variety of incompatible ways.  My understanding is that
ISO 646 isn't a subset of all of the common 7-bit roman
character sets in use.  If that is indeed a correct understanding,
then the ISO 646 effort isn't going to provide a general solution
anyway.

These problems don't have a good general solution because of the
many conflicting extensions/modifications of what was ASCII.
Japanese and Chinese extensions are also a problem in this regard.

My own position is that the standard should not attempt to address
the ISO 646 problem but instead make the "work arounds" (which is
the best way to describe what I hear proposed) implementation 
defined as being outside the scope of the standard.

The standard should use ISO 8859 as the base standard.

Volume-Number: Volume 19, Number 15