Hi, 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 > entity. > 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/> stanza). 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. Any insights? Marvin -- Blog: https://www.guelkerdev.de PGP/GPG ID: F1D8799FBCC8BC4F _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
