There is something that I think you are overlooking.
"Patrik F{ltstr|m" looks correct on a Swedish 7-bit terminal. It looks
hideous with no resemblance to the Swedish reality on a US-ASCII, JIS, or any
other non-Swedish terminal.
The 8-bit equivalent looks correct on a West-Euro 8-bit terminal. It looks
hideous with no resemblance to Swedish reality on a US-ASCII, JIS, or any
other non-West-Euro terminal.
There is no significant difference in the two.
In other words, the only thing that is really accomplished by the 8-bit based
proposals is -- in theory -- to eliminate the problem for Western Europe.
European provincialism and nationalism is an ugly thing whether it is
generating World Wars (and it has done *twice* this century) or if it pushes
character set "solutions" that "solve" the problem for just Western Europe but
at the cost to the rest of the world.
So, let's dismiss the "make the transport pipeline" bigger argument as a non-
starter once and for all. It doesn't solve the international problem. There
is no excuse for such. When the efforts that lead to RFC-822 began in the
late 1970's, the US was the e-mail world. RFC-822 has an excuse for not
solving the international problem.
There has already been a general concensus that the issue of non-ASCII
character sets is unsolvable within the timeframe that we want to get RFC-XXXX
out the door; it is improper for the scope of RFC-XXXX; and further effort to
get this into RFC-XXXX will just cause people to give up on the whole effort
in disgust. I am sure that last result (getting people to give up on the
whole effort) is precisely what PRIME intends.
You must consider, should you choose to use non-ASCII character sets in the
header IN VIOLATION OF RFC-822 what the implications of such a step are. This
is completely unchanged from the past:
a) 8-bit characters are not going to interoperate generally, so only
7-bit national character modified versions of ASCII are safe.
b) it is generally safe to change the Subject: contents.
c) it may be safe to change personal names provided that the modified
characters not occupy certain critical positions. For example, the
US-ASCII characters ( ) < > @ , ; : " [ \ ] are definitely not safe
and perhaps . is not safe either. I believe that the Germans have
umlaut-a where @ is; they can cannot use this character in a phrase
(personal name) -- even quoted -- in any meaningful/interoperable
way.
Also unchanged from the past is that whether or not such a substitution works
within your local enclave, it will not work internationally. The best you can
do is expand the enclave borders to Western Europe. The fact still remains
that when you cross that border your national character name will look
ridiculous compared to an alternate substitution. Such alternate
substitutions exist -- either straight representation in US-ASCII (e.g.
Germans can make umlaut-vowels be the vowel followed by e, and ess-tset be ss)
or a mechanism such as quoted-printable.
Again, there is no change from the past. This has all always been the case.
The situation should be dealt with and made better. But, NOT in RFC-XXXX!
Finally, on a practical basis. No matter what sort of internationalization
standard eventually arises, it will be ignored in the US, Japan, China,
Taiwan, and Korea. It will be ignored in the US because it is unneeded and
unimplementable on a great deal of installed equipment. It will be ignored in
the East Asian countries because it will be unsuitable for their needs AND
because they have a history of rejecting "solutions" imposed upon them by non-
Asians as a matter of principle. One way or another, 7-bit US-ASCII will
remain the ONLY interoperable platform for international communication, no
matter what fantasies you in Europe may have.