On 1 February 2010 14:56, Sergei Golovan <[email protected]> wrote: > 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? >
I think not. My reasoning is that both the original and the new nickname are, as far as XMPP is concerned, the same. To treat this as a nickname change in e.g. Prosody would be difficult, JID normalization happens before the MUC service even sees the stanza. If the MUC component is external, it's even more hopeless. > And what is the recommended way to deal with the situation before all > services fix this bug? > I'm not sure, perhaps clients MUST support stringprep :) I guess I'm not sure why the 110 code on the stanza isn't enough. > 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. > You can set the id on presence stanzas too - it just isn't required. If there is an id attribute and the stanza receives a reply then the id attribute should be included in that reply. (If the specs don't state this then they should IMHO). Matthew
