Hi! It seems that many (if not all) existing MUC service implementations do normalize participants' resources (nicknames) when user joins a room. So, if I send presence to [email protected]/㎐ (a single character U+3390 for a resource) then the service will turn nickname into Hz (two letters H and z). (Tested for ejabberd/mod_muc, prosody/muc, m-link (at conference.jabber.org), mu-conference.) This means that if a client doesn't do stringprep itself it cannot tell if it joined the room or not (except for positive result and having code 110 in some received presence). Any error response can't be reliably processed too. As far as I understand, XEP-0045 does allow to change nicknames, but strictly requires to add code 210 which no tested service did. (BTW, about 210. It is required that own presence packet comes the last in a join series. This means that if the server changes my nickname, ans there's someone with the same nickname in the room, then I'll see his presence before I know that my nickname is changed. This is confusing.)
So, should this normalization be treated as a nickname change? And what is the recommended way to deal with the situation before all services fix this bug? Another issue is reporting join errors. If I throw two joining presence packets (both of which will bounce with different errors, say, conflict with existing user and conflict with a registered nickname) then I can't recognize which returned error corresponds to which initial presence (except for a bit unreliable timing - the first error comes to the first presence). For IQ packets I'd look at id attirbute. Wouldn't it be better to require id for join and change nickname presence packets and mirror them when replying with error? (Moreover, all above implementation do this, but there's an IRC transport which doesn't.) Cheers! -- Sergei Golovan
