> 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
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.
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
> 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 .
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.
> 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" […]/>
> In this case, the identity element would be assumed to have the language
> 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...
Standards mailing list