No charset, no charset problem.
Umm.. if you want to get technical, the 3rd letter of my last name is
not representable in ISO8859-1 (it is the e-with-horizontal-bar found at
code position 186 in 8859-4). This code point in 8859-1 is a superscript
zero-with-underline (or something that looks like that). This *is* a problem.
No charset, no problem.
'K' 'l' ESC - D 0xba 't' 'n' 'i' 'e' 'k' 's'
is what you need, the definite way to declare the third character is
of 8859/4.
And, if the 3rd last letter 'e' of your name happens to be zero-with-underline
(the official name seems to be masculine ordinal indicator, but I don't
what it means) of ISO 8859/1, the sequence:
'K' 'l' ESC - D 0xba 't' 'n' 'i' ESC - A 0xba 'k' 's'
will do, which is impossible to represent with MIME's charset switching
mechanism between ISO-8859-[14].
Existing terminals or terminal emulators which support both Latin 1 and
4 can recognize the escape sequence and display all the characters
correctly.
You can also use the, a little lengthy, pure 7bit sequence:
'K' 'l' ESC - D SO 0x3a SI 't' 'n' 'i' ESC - A SO 0x3a SI 'k' 's'
which is the reason why we don't need 8bit transport for the
internationalization. For further information, see draft-ohta-text-
encoding-01.txt. As we already have an implementation which support
Latin 2, 3 and 4, I'm happy to add them to our draft if you can feed
me some information on actual use.
As for 8bit issues, to legitimate the existing local conventions,
standardization of just-send-8bit is favorable. But as they are
already running and interoperating, we don't need it in hurry.
Masataka Ohta