On Tue, 25 Sep 2001 16:39:14 PDT, Dave Crocker said:
Equally, it is clear that the strongly international quality to the IETF
requires permitting at least SOME encoding of non-ASCII. As you note, at
least being able to encode a person's name properly would seem more than
appropriate.
If we're allowing non-ascii, it has to be able to encode the string:
Valdis Kl=?iso8859-4?Q?=BA?=tnieks (or utf-8/unicode/etc equivalent).
Yes, 8859-4, not -1. I'm getting tired of "solutions" that only work
for 8859-1, or for only one 8859-X at a time. ;)
This however *does* raise a ettiquette/stylebook question:
My mail software is able to deal with 2022-encoded text, and I've often
gotten mail that starts off with:
On Wed, 5 Sep 2001... <kanji or kana string here> said:
Now, that *displays* just fine for me, but I have to admit being unable
to look at a string of kanji and decide "recognized name" or "never heard
of this person before" the way I can for roman-based names. Do we
want to encourage those whos names are non-roman-based include a roman
transliteration for the linguistically challenged, or do I need to
just learn how to deal?
This is probably a different aspect of how to downgrade for those of us
who dont have supra-ASCII display ability. For instance, the problematic
character in my name is an 'e' with a short horizontal bar over it -
I've gotten used to having it smashed to an ascii 'e'. I admit having NO
idea what to do for those of us who use Cyrillic, or Hebrew, or Arabic,
or Kanji, etc....
/Valdis (who knows full well this sort of thing is why we decided on ASCII
the *last* time this issue came up ;)