Hi! It seems to me that new version 1.5pre5 of XEP-0115 (Entity capabilities) contains unnecessary complications (in comparison with more clear 1.4).
I think that it's not a good idea to send disco#info query to a specific node (concatenated node and ver attributes). Instead, queries should be sent to peer's JID without any node (as it is specified in version 1.4 of the XEP). If I understand correctly, this change was made for two reasons: 1) to make disco#info query the same as in version 1.3 of the XEP; 2) to prevent race condition when disco#info query is sent after the peer has changed features list (so, the new features list generates a different hash value). The first problem I see is that a client which indeed able to change its features must remember hashes for all possible combinations of features (at least those combinations which appeared in the current session). Otherwise, it simply can't answer disco#info query correctly. The second problem is that the answer to a disco#info query doesn't reflect a current client capabilities. So, the XEP introduces another race condition (which is worse in my opinion). Moreover, since the hash can be calculated in my client, I can hash the peer's capabilities without any info from his presence. And it's likely that the next capabilities hash in the presence packet will be this new one and not old one (which should reduce a network traffic little bit). As for compatibility with clients supporting version 1.3 I would say that it should be optional and separately described. (If you don't see algo attribute then send disco#info to a node#ver. If you receive query to node#ver then reply to it or whatever.) Probably the 'node' attribute should be made optional too and should be used only if a client wants to be compatible with 1.3. But if it's desirable then some degree of compatibility may be required. Cheers! -- Sergei Golovan
