From donn@hpfcrn.fc.hp.com Fri Sep 13 23:05:52 1991
Received: from relay.hp.com by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8)
	id AA17487; Fri, 13 Sep 91 23:05:52 +0200
Received: from hpfcrn.fc.hp.com by relay.hp.com with SMTP
	(16.6/15.5+IOS 3.13) id AA05825; Fri, 13 Sep 91 14:05:48 -0700
Received: from hpfcdonn.fc.hp.com by hpfcrn.fc.hp.com with SMTP
	(16.7/15.5+IOS 3.22) id AA22384; Fri, 13 Sep 91 15:05:29 -0600
Message-Id: <9109132105.AA22384@hpfcrn.fc.hp.com>
To: greger@ism.isc.com ("greger@ism.isc.com (Greger Leijonhufvud, ISC,
    High Wycombe, U.K.)"),
        keld@dkuug.dk, wg15rin@dkuug.dk, hlj@posix
Subject: Re: (wg15rin 142) Re: Ballot resolution 
In-Reply-To: Your message of "Fri, 13 Sep 91 18:48:14 BST."
             <9109131748.AA15264@> 
Date: Fri, 13 Sep 91 15:05:27 MDT
From: Donn Terry <donn@hpfcrn.fc.hp.com>
X-Charset: ASCII
X-Char-Esc: 29

(Resend... apologies for duplications.)

Keld:

I'm the one who had the ballot objection, and I consider the resolution
that was actually applied marginal at best.  (I might even object to
it as worse.)

What I was trying to do with the original objection was simplify life a
little for everyone, by taking advantage of a specific characteristic
of ISO 646.

In the case of the $ (dollar and "twinkle") and # (pound and pound sterling)
cells, there are only two possible characters authorized by ISO.  No
other substitutions are legal.

It seems unnecessary to me to introduce a mechanism that costs extra,
that in an ideal (no 646 character set problems) would not be needed,
and is subject to abuse.  (How about setting the comment character to
"a", just for grins; let's confuse everyone!   That's a job for Obfuscated
C.)

Since for the comment character there are exactly two possibilities, my
original objection, and the one I'd like to see accepted, is that 
EITHER character, or both if they appear in the current character set,
is the comment character.

This has the advantages that:

	Users have a constant comment character (or at worst two).

	Translation between character sets is simplified (at least
	in that case) because it often goes across as a bit pattern.

	In addition, translation is simplified because you don't have
	the problem of dealing with the situation where you are translating
	from a character set that has only one (e.g. any 646 set) to one
	that has both.  You can translate # to either # or sterling,
	and it will still work.


I wish there were as simple a solution to the problem for backslash, but
since it is unrestricted national usage, there doesn't seem to be one
that doesn't step on someone's toes.  (I'd rather that 646 just went away
completely in favor of 8849 or better.)

Donn


------- End of Forwarded Message