[Standards] XEP-0115 Entity Capabilities - clarifications

Will Thompson will.thompson at collabora.co.uk
Mon Aug 16 11:21:06 UTC 2010


On 16/08/10 12:11, 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.
>
>> 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.

This was added to work around a bug in iChat: if you send back 
item-not-found, it will just ask you again, immediately, forever.

So while sending <item-not-found/> should work, it only works if you 
don't know anyone using iChat. :)

-- 
Will



More information about the Standards mailing list