Comment 3 for bug 332713

I don't know if the function dlh tested is used at all for authentification.

I tried to login with Agent Zéro (0.2.8.3_beta1 & 0.2.8.2.1) both a login name like below.

(00:58:22) joda_bot: ct|kyle: brb, I'll try to auth with his name, and see if I get wrong password or wrong user
(00:58:38) joda_bot: if you can monitor authentification that data might prove helpful
(00:59:18) ct|kyle: yes i can look at the @ct
(01:01:24) ct|kyle: joda_bot: UNKNOWN_USER Agent Z?FFFFE9ro
(01:01:48) joda_bot: yeah that I got on the client too
(01:01:51) ct|kyle: joda_bot: same
(01:02:06) joda_bot: wait I'll try a 0.2.8.2.1 client
(01:02:18) ct|kyle: somwhow ?FFFFE9 needs converted to é

From my perspective anything not using a "sane" charset is a bug. The escape is not UTF-8 nor another valid charset escape I know. A valid unicode escape should have 00 instead FF bytes (AFAIK?). Is this the "signed char problem" you describe?

My view:
I suggest that a certain (universal?) charset is used for the authentification process - otherwise the protocol should send the charset used. Note just escaping bytes with URLEncode won't fix things either as the auth-server then still does not know how to convert those bytes to characters. URLEncode with a specific charset should work.