An entity is able to query (subject to appropriate access rights) an archive for all messages within a certain timespan, optionally restricting results to those to/from a particular JID. To allow limiting the results or paging through them a client may use &xep0059;, which MUST be supported by both the client and the server.
-A query consists of an &IQ; stanza addressed to the account or server entity hosting +
A query consists of an &IQ; stanza of type='set' addressed to the account or server entity hosting the archive, with a 'query' payload. On receiving the query, the server pushes to the client a series of messages from the archive that match the client's given criteria, and finally returns a &MESSAGE; with a <fin/> tag to indicate that the query is completed.
@@ -337,7 +337,7 @@Sometimes (e.g. due to network or storage partitioning, or other transient errors) the server might return results to a client that are unstable (e.g. they might later change in sequence or content). In such a situation the server MUST stamp the <fin> element with a 'stable' attribute with a value of 'false'. If the server knows that the data it's serving are stable it MUST either stamp a 'stable' attribute with a value of 'true', or no such attribute. An example of when unstable might legitimately be returned is if the MAM service uses a clustered data store and a query covers a time period for which the data store has not yet converged; it the server could return best-guess results and tell the client that they may be unstable. A client SHOULD NOT cache unstable results long-term without later confirming (by reissuing appropriate queries) that they have become stable.
In order for the client find out about additional fields the server might support, it can send an iq-get addressed to the archive like this:
+In order for the client find out about additional fields the server might support, it can send an iq stanza of type='get' addressed to the archive like this: