On 2/1/10 8:30 AM, Matthew Wild wrote: > 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.
Me, neither. >> 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). That's handled in the RFCs, no special reason to mention it in XEP-0045, but I'll add something about it just in case. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
