[jdev] XEP-0115: Distinguishing new usage of 'ver' attribute as hash from old usage as version string.

[Armando Jagucki]

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 
capabilities.

<presence>
  <c xmlns='http://jabber.org/protocol/caps'
     node='http://exodus.jabberstudio.org/caps'
     ver='0.9'/>
</presence>

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. :)


Regards,
-- 
Armando Jagucki