[Standards] Entity Capabilities 2.0
jonas at wielicki.name
Mon Feb 12 08:03:18 UTC 2018
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:
> 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:
> 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
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
Will do, thanks.
> - Typos found: „sevre“, „Cabability“
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards