From donn@hpfcrn.fc.hp.com Tue Apr 23 15:53:56 1991
Received: from [15.254.48.2] by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8)
	id AA00201; Tue, 23 Apr 91 15:53:56 +0200
Received: from hpfcrn.fc.hp.com by hpfcla.fc.hp.com with SMTP
	(15.11.1.6/15.5+IOS 3.20) id AA23624; Tue, 23 Apr 91 07:52:52 -0600
Received: from hpfcdonn by hpfcrn.HP.COM; Tue, 23 Apr 91 07:54:01 -0600
Message-Id: <9104231354.AA13510@hpfcrn.HP.COM>
To: erik@sra.co.jp
Cc: wg15rin@dkuug.dk
Subject: Re: (wg15rin 101) Re: symbolic names in localedef 
In-Reply-To: Your message of "Mon, 22 Apr 91 21:19:03 U."
             <9104221219.AA09498@sran8.sra.co.jp> 
Date: Tue, 23 Apr 91 07:53:58 MDT
From: Donn Terry <donn@hpfcrn.fc.hp.com>
X-Charset: ASCII
X-Char-Esc: 29

I'm inclined to agree with Erik: let the characters which are in practice
invariant (ISO 646 invariant) represent themselves, always.

In general, with localedef, I detect a tendency to go too far with 
generalization.   Anything that can be relied upon to work reasonably
with a simple translation (such as ASCII <-> EBCDIC) should rely on
the translation for portability (that is, those characters which appear
in the portable character set description).

I realize that I'm on thin ice here: the ability to change the comment
and escape characters is marginal in terms of its value, as well.  This
can also be done by a simple translation (using tr, e.g.) in the process
of importing the localedef file.  (I believe it's fair to make two
assumptions here: (a) that there is a working system operating in some
POSIX-conforming character set, and (b) it is possible to import data
from another system in a fashion such that tr could be used on it.  If
either of these assumptions is violated, I don't think we're in a space
that is interesting for standardization.)  I don't *think* that either
comment or escape are context dependent (in that if they appear they always
have their defined function, or yeild an error.)

Donn