[Standards] Comments about XEP-0115 v.1.5pre5 (SVN)
sgolovan at nes.ru
Thu Aug 30 14:21:19 UTC 2007
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
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.
More information about the Standards