Joe Hildebrand and I have been working on some tweaks to our beloved XEP-0115 (Entity Capabilities), based on feedback we have received from developers who have been implementing the updated version 1.4. Yes we're sorry to be tweaking it so soon, but we think it's better to fix things sooner than later.
You can see the changes here: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1145&r2=1194 http://www.xmpp.org/extensions/tmp/xep-0115-1.5.html The issues are as follows: 1. Joe and I miscommunicated about whether it's necessary to include the 'hash' attribute. This is a helpful flag to indicate that the caps data follows the new spec version, so we've made it required from now on. 2. It is confusing to call it the 'hash' attribute, since now the 'ver' attribute includes the hash. This is more of a communication issue than anything else (Developer1 to Developer2: "does it include the hash?" Developer2 to Developer1: "do you mean 'does it include the hash attribute' or do you mean 'is the ver attribute generated according to that fancy new method'?"). So we propose changing the name of the 'hash' attribute to the 'algo' attribute, since it specifies which algorithm is in use. 3. We've removed the XML schema default of "sha-1" for the 'algo' attribute, since not including the 'algo' attribute does not that you used the SHA-1 algorithm -- it means that you generated the 'ver' value according to the legacy approach. 4. There is a potential race condition if you don't send the disco#info request to a disco node of "capsnode#capsver" as we did in the legacy approach. That is, if I log in and send you presence, but enable a plugin that changes my supported features before you send me the disco#info query, you'll get bad results. If I know that you want the features that I supported before I enabled the plugin, I can send you the right results. See the spec for examples. 5. As Kevin Smith requested during the Council vote, we are suggesting that the value of the caps 'node' attribute be a concatenation of the product URL (e.g., "http://psi-im.org/";) and the software version (e.g., "0.11"). In the Council meeting, we decided this could be generated as "ProductURL#SoftwareVersion". However, if we're sending the disco#info request to "node#ver" then we need to prohibit the "#" character in the 'node' attribute. Therefore Joe and I suggest that we change the separator character from "#" to ";" in the 'node' attribute. See the spec for examples. 6. We updated the security considerations slightly to mention that the service discovery 'name' attribute is ignored when generating the hash. 7. We more fully specified how the processing entity should handle caps data generated according to the legacy format. 8. We explicitly flagged the 'ext' attribute as deprecated, not optional. Feedback is welcome as always. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
