[Standards] Entity Capabilities 2.0

Jonas Wielicki jonas at wielicki.name
Wed Feb 14 20:55:30 UTC 2018

Hi Christian,

Thanks again for your input. Comments inline.

On Dienstag, 13. Februar 2018 23:20:54 CET Christian Schudt wrote:
> 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. <c>
> <hash algo=„sha-1“>abc</hash>
> <hash algo=„sha-256“>def</hash>
> </c>
> <c>
> <hash algo=„sha-256“>def</hash>
> <hash algo=„sha-1“>abc</hash>
> </c>
> 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.

I honestly didn’t think about that, since my implementation does ignore the 
order between the hash elements and simply tries them in the order of the 
local hash function preference. I’ll include a few implementation notes on 
this topic in the XEP, thank you very much.

> 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.
> *confusing*?

I assume you’re referring to §7.2, Upgrading from XEP-0115. I think you missed 
the "without verification" qualifier in the last sentence which should make 
things clearer: *if* a XEP-0115 cache is available and *no* XEP-0390 caps 
hashes are received, an entity MAY choose to still optimize the query by 
falling back to the XEP-0115 behaviour. However, if XEP-0390 caps hashes ARE 
available, the entity MUST use them to verify the data obtained from a 
XEP-0115 cache (if they have no XEP-0390 match and went down the fallback 
route). I think a rewording will make this much clearer.

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

I’m not sure if the XEP is the right place for that, honestly. I’d like to 
restrict it to describe protocol, not to implementation details which are 
solely in the realm of the Software Engineering side of things (which is in 
contrast to the things we discussed above, about the Cache implementation).

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

But this is behaviour which is visible to other entities. A client might 
implement XEP-0016 *and* XEP-0191, or one client may implement XEP-0191 and 
one client may implement XEP-0016 and to gain some meaningful interoperation 
between the two approaches it is kinda needed. It is not visible to other 
entities if you use a common interface for your XEP-0115 and XEP-0390 
implementations or not.

We can of course make a huge section of implementation suggestions, but I 
don’t think this is the right place to do that.

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

I’m using the disco#info @node values (Capability Hash Node in XEP-0390 
terminology) as cache keys for the (caps -> disco#info) cache. They are 
different and already include the hash function and hash, and there’s no need 
to run SHA1 on top of that.

thanks and kind regards,

   [1]: https://github.com/xnyhps/capsdb/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180214/fd0c4268/attachment-0001.sig>

More information about the Standards mailing list