[Standards] Entity Capabilities 2.0

Jonas Wielicki jonas at wielicki.name
Mon Feb 12 08:03:18 UTC 2018

Hi Christian,

First of all, thank you for your thorough feedback. My comments are inline 

On Montag, 12. Februar 2018 00:41:54 CET Christian Schudt wrote:
> Hi,
> I’ve implemented Entity Capabilities 2.0 (XEP-0390) and like to share some
> thoughts about it here and in the following link.
> I think it could be interesting for library developers as well as the
> author(s) of XEP-0390:
> http://babbler-xmpp.blogspot.de/2018/02/experimenting-with-entity-capabiliti
> es.html
> Generally, XEP-0390 is really well and comprehensively written, but I’ve
> found some issues during development, which I’d like to address:
> - How to pick the first Capability Hash from a Capability Hash Set. Is it
> random? Is there a preferred hash algorithm order?

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?

(I’m still unsure I understood you correctly.)

> - It’s not specified
> what to do if a hash algorithm is not understood by a processing entity.
> I’ve implemented it in the way that it’s ignored and the next hash is
> tried.

Yes, ignoring is the way to go. I can make that clearer.

> - § 6.2 Rules for Processing Entities is relatively short. As
> outlined in my blogpost this section could be more verbose: Integration
> with XEP-0115. Picking the first hash. When to do a disco#info query.

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

When to do the disco#info query is essentially up to the processing entity. In 
my implementation, I do the query only when the application first asks for the 
information, to save bandwidth. Again, I’m not sure if there should be 
normative language on this.

> - I
> am also missing a cache which maps entities to capabilities, i.e. JIDs to
> disco#info objects. This is the whole point of the XEP (to be able to know
> an entity’s abilities without service discovery). This cache should be
> probably be non-persistent. The "Capability Hash Cache“ (hash ->
> disco#info) is actually only the intermediate/auxiliary cache.

I see. I makes sense to specify this in the XEP, indeed.

> - It is
> said, that the disco#info element can have an xml:lang element, but it’s
> not specified in XEP-0030. What about it?

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.

> - What about the xml:lang element
> in the stream header, i.e. the sessions default language? If it is set, is
> it also an „implicit language“ used during construction of the Caps String?

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" […]/>

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.

> - Generally I am unsure if using the "xml:lang" and „name" from the
> identities is a good idea at all, because these two attributes should not
> change the capabilities of an entity. Name and language is just for humans.
> I.e. if a server sends german identities for one user and english
> identities for the next user (depending on their client settings/stream
> header), the server still has the same identities, which should result in
> the same verification string, shouldn’t it?

I will send a separate email for this, thank you for bringing it up.

> - Decomposing a Capability Hash
> Node is not needed afaik. Having it specified is slightly distracting
> because you think you need it.

It may be needed when a client processes disco#info queries for those nodes, 
depending on the implementation. Of course, an implementation may simply use 
them as opaque strings, but it may also handle them separatedly. Since it’s 
trivial to get wrong, but also trivial to write it down correctly, I thought 
it’d make sense to have it there.

> - The ‚var‘ element will be before the
> ‚<value/>‘ element in the verification string. Therefore it would be
> clearer if the description first mentioned the ‚var‘ attribute and then the
> ‚<value/>‘.

Will do, thanks.

> - Typos found: „sevre“, „Cabability“


kind regards,
-------------- 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/20180212/20ff8bb1/attachment.sig>

More information about the Standards mailing list