Sergei Golovan píše v Po 01. 02. 2010 v 17:56 +0300: > Hi! > Hello. :)
> 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). Except is essential here. You can simply infer the success from the fact you received something else than error. Though I agree implementing MUC does require some imagination, it's not as impossible as you present it to be. > Any error response can't be reliably > processed too. How so? Use the 'id' attribute. > 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 it should and that this possibility should be noted in the spec. > And what is the recommended way to deal with the situation before all > services fix this bug? > Work around it somehow. Most services have various bugs at the moment and they will have more once the MUC review is over. ;) And, if possible, spam service developers and admins as much as you can with requests to fix it. > 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.) > Why require it? You simply add it if you need it. Handling of the 'id' attribute is clearly defined in the RFC's. It has to be mirrored if present. > Cheers!
signature.asc
Description: Toto je digitálně podepsaná část zprávy
