[Standards] XEP-0115 Entity Capabilities - clarifications
martin.morrison at gmail.com
Mon Aug 16 13:42:13 UTC 2010
Alban Crequy wrote:
> Le Sun, 15 Aug 2010 23:05:49 +0100,
> Martin Morrison <martin.morrison at gmail.com> a écrit :
>> 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):
>> 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?
> I think <item-not-found/> is best: sending an empty capability in this
> case is bad because the hash will not match and the client will discard
> the reply.
This assumes that the receiving entity re-extracts the hash from the
node on reply. If I write a client that chooses to generate uuids for
the node attribute, then I am fully compliant with XEP-0115, but your
client will never tell me your capabilities.
If what you've suggested is the recommended behaviour, shouldn't the
specification use "MUST" when specifying "node#hash" as the value of the
>> 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.
> For this race, it was suggested to just send <item-not-found/> in this
> thread: http://mail.jabber.org/pipermail/standards/2008-May/018713.html
> Sending <item-not-found/> will work: Juliet will receive the new hash
> a bit later and she will send a new disco request with the new hash.
> Alternatively, Telepathy-Gabble keeps a cache mapping
> hash->capabilities. So with this implementation, Romeo will send the
> *previous* capabilities corresponding with the requested hash. Juliet
> will ask the capabilities again anyway when she receives the new hash
> if she wants to know the new capabilities.
This requires Romeo to keep track of the hashes of every combination of
capabilities he has every published. It also doesn't sit well IMO with
the existence of multiple hashing algorithms - the "node#hash" 'node'
attribute doesn't tell you what the hashing algorithm is, making it even
harder to know what capabilities to return (albeit on the very unlikely
off-chance that two different capabilities hash to the same string under
two different supported algorithms).
> Disco queries in XEP-0115 are not "what are your current caps?" but
> "what are the caps corresponding to this hash?". It is up to the
> clients to keep track of hashes and to make new disco requests when
> they receive a new hash if they want to know the capabilities.
If they really are, as you say, "what are the caps corresponding to this
hash?" then shouldn't the request mirror that, by explicitly specifying
the hash algorithm and hash string? Currently the request on-the-wire
would be interpreted as "what are the caps of the node known as
'node#hash'?", with nothing to differentiate this from a plain XEP-0030
I agree with the sentiments of your points, but the current
specification feels like its trying to pander to the legacy format too
much, resulting in multiple ambiguities overall.
More information about the Standards