Re: I-D ACTION:draft-brezak-spnego-http-00.txt

[Valdis.Kletnieks at vt.edu]

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 ;)