[Standards] Entity Capabilities 2.0

Christian Schudt christian.schudt at gmx.de
Sun Feb 11 23:41:54 UTC 2018


I’ve implemented Entity Capabilities 2.0 (XEP-0390) and like to share some thoughts about it here and in the following link.

I think it could be interesting for library developers as well as the author(s) of XEP-0390:


Generally, XEP-0390 is really well and comprehensively written, but I’ve found some issues during development, which I’d like to address:

- How to pick the first Capability Hash from a Capability Hash Set. Is it random? Is there a preferred hash algorithm order?
- It’s not specified what to do if a hash algorithm is not understood by a processing entity. I’ve implemented it in the way that it’s ignored and the next hash is tried.
- § 6.2 Rules for Processing Entities is relatively short. As outlined in my blogpost this section could be more verbose: Integration with XEP-0115. Picking the first hash. When to do a disco#info query.
- I am also missing a cache which maps entities to capabilities, i.e. JIDs to disco#info objects. This is the whole point of the XEP (to be able to know an entity’s abilities without service discovery). This cache should be probably be non-persistent. The "Capability Hash Cache“ (hash -> disco#info) is actually only the intermediate/auxiliary cache.
- It is said, that the disco#info element can have an xml:lang element, but it’s not specified in XEP-0030. What about it?
- What about the xml:lang element in the stream header, i.e. the sessions default language? If it is set, is it also an „implicit language“ used during construction of the Caps String?
- Generally I am unsure if using the "xml:lang" and „name" from the identities is a good idea at all, because these two attributes should not change the capabilities of an entity. Name and language is just for humans.
I.e. if a server sends german identities for one user and english identities for the next user (depending on their client settings/stream header), the server still has the same identities, which should result in the same verification string, shouldn’t it?
- Decomposing a Capability Hash Node is not needed afaik. Having it specified is slightly distracting because you think you need it.
- The ‚var‘ element will be before the ‚<value/>‘ element in the verification string. Therefore it would be clearer if the description first mentioned the ‚var‘ attribute and then the ‚<value/>‘.
- Typos found: „sevre“, „Cabability“

Kind regards,
— Christian

More information about the Standards mailing list