[Standards] XEP-0115 Entity Capabilities - clarifications

Alban Crequy alban.crequy at collabora.co.uk
Mon Aug 16 14:40:30 UTC 2010


Le Mon, 16 Aug 2010 14:42:13 +0100,
Martin Morrison <martin.morrison at gmail.com> a écrit :

> Alban Crequy wrote:
> > Le Sun, 15 Aug 2010 23:05:49 +0100,
> > Martin Morrison <martin.morrison at gmail.com> a écrit :
> > [...]
> >> 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.

With XEP-0115 version 1.5, the receiving entity have to re-extracts the
hash from the node on reply as described in section "5.4 Processing
Method" (point 3.7.).

If you choose to generate uuids for the node attribute, you will not
publish hash='sha-1' and none of your contacts will be able to
reconstruct the hash, so they will fallback to the old XEP-0115 version
1.3 method to avoid cache poisoning.

> If what you've suggested is the recommended behaviour, shouldn't the 
> specification use "MUST" when specifying "node#hash" as the value of
> the 'node' attribute?

Maybe it should be better explained.

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

Yes, we assume that an entity use only one hash method to advertise
its capabilities. But the current XEP define only one method at the
moment: "sha-1".

In the case the XEP defines several hash methods in the future, you
have to keep in memory which hash method is using your contact
(advertised in the <presence> stanza) in order to check the hash. We
have to assume that your contact does not change its hash method...

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

So an implementation before XEP-0115 v1.5 can still request and receive
capabilities from an XEP-0115 v1.5 implementation :)

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

I think it is good to stay compatible with the legacy format, and the
ambiguities can be resolved with better explanations in the XEP.

Cheers,
Alban



More information about the Standards mailing list