[Standards] XEP-0115 (caps): Validation string processing incomplete?
m-guelker at phoenixmail.de
Wed Feb 22 20:07:28 UTC 2017
XEP-0115 (Entity Capabilities), §5.4 says this:
> When an entity receives a value of the 'ver' attribute that appears to
> be a verification string generated in accordance with the generation
> method defined in this specification, it MUST process the 'ver'
> according to the following method.
It then goes on and states in Nr. 3:
> If the value of the 'hash' attribute matches one of the processing
> application's supported hash functions, validate the verification
> string by doing the following:
> a) Send a service discovery information request to the generating
> b) Receive a service discovery information response from the
> generating entity.
This requirement is stipulated unconditionally, which means, if I take
it literally, I need to follow it *every time* I get a <c/> element with
a 'ver' attribute, regardless of whether I cached the 'ver' value
(validation string) or not. That in turn would mean I have to send
service discovery queries each time I receive a <c/> element, which
contradicts the motivation of XEP-0115 outlined in its §1 below the
bullet list, as it would mean to send service discovery queries all the
time when I receive <presence/> stanzas (especially given that §6.1 says
client SHOULD send the capabilities information with every <presence/>
Shouldn't there be a list item in §5.4 before Nr. 3 a) that says
something like "If the verification string received is equal to a
verification string already validated and cached using the mechanism
outlined below, stop processing here"?
I see that in Nr. 3 h) I am advised to cache the result value, but this
doesn't play good with the hard MUST requirement at the beginning of
§5.4 that doesn't take the cache into reference. The only reason I could
imagine to query for a cached verification strings' entity service
discovery information is a broken client that sends out the same
verification string even if it changes features, but that is a case that
I think shouldn't be catered for as it is a clear violation of the
generation of the validation string as described in §5.1.
PGP/GPG ID: F1D8799FBCC8BC4F
More information about the Standards