[jdev] XEP-0115: Distinguishing new usage of 'ver' attribute as hash from old usage as version string.
armando.jagucki at jivesoftware.com
Wed Feb 6 16:38:23 CST 2008
Version 1.4 of XEP-0115, Entity Capabilities, changes the usage of the 'ver'
attribute sent with a presence packet. In clients supporting an older version
of XEP-0115, they use this attribute to signify the version of the client.
With version 1.4 of the XEP, the 'ver' attribute is used as a hash containing
the capabilities of the client (identities and features).
XEP-0115 states: "The client MUST check the identities and supported features
against the 'ver' value by calculating the hash as described under Generating
the ver Attribute and making sure that the values match. If the values do not
match, the client MUST NOT accept or cache the 'ver' value as reliable and
SHOULD check the value of another user who advertises that value (if any).
This helps to prevent poisoning of entity capabilities information."
Let us examine the case where a client connects with a 'ver' attribute
containing a version string (eg. an older client), and not a hash of its
The server checks its cache for a 'ver' hash of '0.9' and after noticing it is
not present it sends a disco#info to discover the client's capabilities. When
the capabilities are returned the server generates a hash as described in the
XEP and then compares this generated hash with the received 'ver'
string, '0.9', which will of course not match. If I understand correctly, the
server must NOT cache the capabilities because they could not be verified,
and they may have been poisoned.
As you can see, the server will never cache the capabilities for the older
clients, because their 'ver' attributes will never match the generated hash.
This results in the server sending out a disco#info on each presence since
the capabilities will never be added to the cache. Sending a disco#info
request on each presence is of course not ideal.
How then can we distinguish between the new usage of 'ver' attribute as a hash
from the old usage as version string. Am I misunderstanding something here? I
read that the new XEP was backwards compatible with clients implementing the
older version. What are the cache rules for these 'old' clients?
P.S. This is the current behavior in Openfire, as I implemented it myself. Joe
Hildebrand noticed the extraneous disco#info packets and brought it to Gato's
attention who brought it to mine. :)
More information about the JDev