From 82044132e49d203627828e3898f79121ec3f3398 Mon Sep 17 00:00:00 2001 From: Kevin Smith Date: Tue, 30 Sep 2014 11:50:31 +0100 Subject: [PATCH] Make the use of set explicit in 313 --- xep-0313.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xep-0313.xml b/xep-0313.xml index e6097940..7c812dbe 100644 --- a/xep-0313.xml +++ b/xep-0313.xml @@ -141,7 +141,7 @@

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: