[Standards] XEP-0115: some tweaks

Peter Saint-Andre stpeter at stpeter.im
Wed Aug 29 17:40:14 UTC 2007


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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070829/b840109f/attachment.bin>


More information about the Standards mailing list