Re: Reviewing philosophies and assumptions

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

>   Strawman: At the transport, receipt, and sending levels, an extended
> SMTP server supports 8 bit data paths.  If it does not do that, it
> isn't an extended SMTP server, it rejects the verbs(s), and it is held
> responsible for 7 bit ASCII only.  What an extended (8 bit) SMTP server
> does to transfer 8 bit information into a 7-bit-character-host is up to
> it and the host, and none of the Internet's business.

I think leaving the 8-bit -> 7-bit MTAs communication unspecified
would mean the same as creating a big mess...

>   Now, one can get rid of much of that by adopting the symmetric
> argument, which is "7 bit always, you never need 8 bits".  That is, to
> me, second-best.  2x2 matrices are worse.  Much worse.

I tend to agree with you that we can do it all on 7-bit.
That is we could convert everything in the UA / MTA interface.

> Part IV.  Another look at character sets.
>   If we are going to accomodate character sets other than ASCII, there
> are, as far as I know, four approaches suggested by various existing
> and proposed International Standards.  They are:
>   (i) Stick with old versions of ISO 646 and its national variants.  If
> we do this, we need to only identify the national variant.  We also
> don't need an eight-bit data transfer path.  This approach has largely
> been a failure, and is included for completeness only.

Well, it is quite sucessfull till date, I use it a lot!
This is the defacto mail standard in Denmark, Finland, Norway and Sweden.
Something better is needed tho.

>   (ii) Use ISO 2022 and the designation sequences against any
> registered character set.  The problem with this plan is that it is
> very hard to support properly, and "hard to support properly" is nearly
> equivalent, IMHO, to "promoting a loss of interoperability".
> Fortunately, no one has suggested it lately, so let's ignore it.

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.

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? OK; so X has that, but couldn't
X quite quickly get support for 10646?

And how are you to generate a big character set anyway?
How would you generate the full repertoire of the 8859 families?
How would you generate kanji on a keyboard?
You need something like the Japanese input method or DEC compose
character or IBM ALT123 or TEX or troff names, or WordPerfect codes.

What dos the TEX-HEX encoding do for this?
Is there a specification of TEX-HEX?

I strongly beleive that we should not allow MTAs to put restrictions
on the information sent, like "I can only understand this limited
set of character sets". X stations are very capable of handling
a wide set of character sets, and with a myriad of characters -
and X stations are very common these days... It is really very difficult
for the MTA to deem what UAs or other MTAs are able to handle,
so it should be mandatory for the MTA specification of our new
mailing software, that no information should be lost.

>   Also remember that the embedded shifting and designation sequences
> are very sensitive.  If they get garbled (note that these are single
> character errors), you may end up looking at Thai when you expected
> Greek.  An uncomfortable conversion experience, I expect, and a strong
> argument for checksums or ECC.  Do those belong in SimpleMTP?  I think
> probably not.

What I was proposing was just to use a single-shift character,
no locking-shifts. Then one character error would only affect
one or two folloing (possibly single-shifted) characters.

Keld