[Standards] Entity Capabilities 2.0

Christian Schudt christian.schudt at gmx.de
Tue Feb 13 22:20:54 UTC 2018

Hi Jonas,

> You are referring to the processing entities side? The entity is free to 
> choose from the set as it desires. The order of elements inside the hash set 
> is undefined. It could for example iterate a list of hash functions in 
> descending order of preference and look for hashes in the hash set. It could 
> also first check if any of the hashes is in the cache and prefer that.
> I see this could be clarified, but I’m hesitant to make a normative statement 
> on the behaviour. Some suggestions can be put into the XEP though. Do you see 
> a reason to make this normative?

See, you made a good point here: First check if any of the hashes is in the cache.
I forgot about it in my implementation and that’s why I think it could be beneficial to have something defined in the specification.

Think about the same capabilities sent by two different entities, but with a different hash order each.
<hash algo=„sha-1“>abc</hash>
<hash algo=„sha-256“>def</hash>

<hash algo=„sha-256“>def</hash>
<hash algo=„sha-1“>abc</hash>

If an implementation would just pick the first hash each time it processes a presence with Caps, it will likely end up with two service discovery requests and two hashes in the cache, although one would be enough.

The spec should recommend to first iterate over all hashes and check for each hash, if it’s already known (cached).

> I *think* I outlined the integration with XEP-0115 in the XEP already. Can you 
> be more specific on where you would like guidance?

You write (or I understand): If there are also `115 Caps, you may use them to get the disco#info from the cache.
In the next sentence: you must not use data from the 115 cache, if there are also 390 Caps in the presence.

Generally I thought about some guidance about what I’ve worked out during my implementation: Some ideas about a common interface and some business rules for processing both Caps Extensions in the same presence.
In the same sense how XEP0191 describes the relation to XEP0016 and recommends to use the same backend storage and defines a clear mapping [1].

Maybe also some words about if XEP0115 cache can be mixed with XEP0390 cache.
In my implementation I use the same cache for both.
Maybe you also have some recommendations what to use as cache keys.
In my implementation I currently use something like: „sha1(XEP# + algo + bas64(hash)). Not sure if it’s good.

[1]: https://xmpp.org/extensions/xep-0191.html#privacy

> Any element in XML can have an xml:lang attribute. It is specified in the XML 
> standard on how the value of xml:lang propagates.
> Yes, at it propagates down the tree, unless another element (e.g. the 
> presence) overrides it. For example:
> <stream:stream xml:lang="fr" […]>
>  […]
>  <iq xml:lang="de" type="result" […]>
>    <query xmlns="[…]disco#info" xml:lang="en">
>      <identity name="foo" […]/>
>    </query>
>  </iq>
>  […]
> </stream:stream>
> In this case, the identity element would be assumed to have the language "en". 
> If the xml:lang on the query was missing, it would be "de" and so on.

Oh wow, understood. Let’s see what will happen about the language...

— Christian

More information about the Standards mailing list