Re: Reviewing philosophies and assumptions

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

> You mean `kterm', right? Yes, kterm can understand ISO 2022 escape
> sequences for Japanese. And newer kterms can understand other
> sequences too, such as those for Chinese. Sony's mterm understands
> many different sequences, including several for Europe, and does the
> appropriate codepoint mapping to be able to use an ISO 8859-1 font.
> 
> However, software such as mterm that does the Right Thing for many
> different escape sequences is probably relatively rare, so even if we
> suddenly adopt ISO 2022 for exchanging mail all over the world, many
> people will not be able to display languages other than their own (and
> English). But at least it is possible to send messages over SMTP if
> ISO 2022 is used in this way, i.e. 7-bit only.

I am not proposing that we all change to iso 2022 encoding.
I am just proposing that we codify the existing Japanese practice.
Oh, well, with the advent of kterm support for chinese this could
well do for handling chinese (and maybe korean) mail too.

Actually I am proposing that we have specifications to be able to present
and generate quite intelligently *any* mail on *any* terminal
equipment (satisfying ISO 646 invariant character repertoire)
via an universally available 7-bit fallback.

> No conclusions here. Draw your own. :-)
> 
> 
> > 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'm not sure if B-news is relevant in this discussion, but I have been
> told that people had to fix B-news to be able to include escape
> sequences.

Well, we have had a look into that problem too, and found compose characters
which should be able to pass B-news unchanged. The sequence we had in
mind was <space><backspace>, which is by definition quite readable...

Keld