Re: Reviewing philosophies and assumptions

[Keld J|rn Simonsen <keld@xxxxxxxx>]

> I wrote:
> >John, you do not read my mailings carefully!
> >I proposed to standardize existing practise.
> >The Japanese are doing ISO 2022 shifts for mail. 
> >This is actually the only existing practise in bigger
> >character set usage in mail, that I am aware of.
> >I still think the Japanese should get their practise codified.
> >I am not going to write the specs, tho.
>   Actually, I read the mailings very carefully, and this is exactly my
> point.  The largely-undocumented, un-codified, Japanese use of 2022
> shifts, and whatever it means about hardware/workstation requirements,
> does not meet my criteria for what I've learned to define in standards
> circles as "existing practice".  If we were having this discussion
> after the Japanese practice were codified, in general use, and
> available in real implementations outside that country, I would
> probably take a different position.

Well, well, I do consider that you read all this stuff very carefully,
John, so I wondered why you missed my points. Now I know:-)

The Japanese use of 2022 for mail is well documented, but in Japanese.
Their 2022 use is very well documented, as in EUC and other character
set encoding use. It is quite wide-spread, as far as I know.
It is in general use outside Japan, as it is available with every
X implementation - standard. I think you can call X "a real
implementation". Well, I am a bit unhappy about talking on issues
related to Japan, being no Japanese; maybe the people coming
from Japan could enlighten us?

> >About 10646: yes it is not available on current hardware.
> >But the same goes for the full 8859 family. Anybody got support for
> >all 8859 character sets in one device? 
>   Again, not the point.  My concern is what happens if the sending user
> and receiving user don't have access to the same character sets. 

Well, we agree on the points here I think. My assumption is that we need
to cover at least 8859-1, 8859-2, 8859-5 and 8859-7 (Latin-1, Latin2,
Cyrillic and Greek). Not much equipment (except X Windows stations)
has support for all of these at the same time.

> > (MTAs should not loose information)
>  No disagreement.  I'm opposed to MTA's discarding or destroying
> information.  With the exception of the "just truncate the 8th bit,
> maybe you can figure it out" community, I can't imagine anyone favoring
> MTAs losing information.  What I'm trying to do is propose ways in
> which an MTA can decline to accept anything it can't handle without
> information loss.  It might be that your arguments about, say, X
> clients, argues that all MTAs *should* run "transparent".  But I'd like
> to see provision for those that don't/won't/ can't.

Well, if we can have an encoding in pure 7-bit of the full character 
repertoire needed, then any MTA - including
bitnet, decnet, uucp should be able to run transparent?
I agree that it should be the responsibility of the sender to
do this encoding.

Keld