Hi, 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: http://babbler-xmpp.blogspot.de/2018/02/experimenting-with-entity-capabilities.html 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 _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
