[Standards] XEP-0115 Entity Capabilities - clarifications

Martin Morrison martin.morrison at gmail.com
Sun Aug 15 22:05:49 UTC 2010

I've recently been implementing XEP-0115 Entity Capabilities, both the
latest and the legacy versions, and have a few issues that I feel
should be clarified in the latest version of the spec:

1. The legacy version of the spec explicitly says (in 4.2, below example 8):

"Note: The set of features that a given entity advertises in response
to a "client#version" request and all "client#extension" requests MUST
be equivalent to the response it gives to a disco#info request with no
'node' attribute".

The latest revision of the spec does not have a similar clause (for
"client#hash" == no 'node'). I assume this what is intended though,
and feel it could do with being made explicit.

2. The spec only uses the word "SHOULD" when specifying how the Disco
'node' attribute is formed. A receiving entity that supports both
Entity Capabilities and has multiple disco#items nodes thus has
somewhat of a dilemma in deciding how to respond to a disco#info
request for an unknown node. Should it return an <item-not-found/>
error, or assume that the remote entity has used some other mechanism
to construct the 'node' attribute in the request, and return the base
capabilities as if the node was empty?

3. Related to item 2, the following race condition can occur:

- romeo at shakespeare.lit sends Presence to juliet at shakespeare.lit with
an Entity Capabilities hash
- In response, juliet sends a disco#info request with the "node#hash"
as the 'node' attribute
- Meanwhile, romeo changes the feature set of his client (e.g. turns
on his camera)
- Upon receiving the disco#info request, what does romeo do?

As the 'node' attribute has been formed using the recommended method,
Romeo can establish that the hash doesn't match his current
capabilities. Should he return an error, or ignore the contents of the
'node' attribute completely and just return his current capabilities
(which will be accepted, since he will already have pushed an updated
hash via Presence)? Either way, I think it would help if the spec
specified what was expected.


More information about the Standards mailing list