moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

Make the use of set explicit in 313

This commit is contained in:
Kevin Smith 2014-09-30 11:50:31 +01:00
parent cbe0abb8ab
commit 82044132e4
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
xep-0313.xml
View File

@ -141,7 +141,7 @@
<p>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.</p>
<p>A query consists of an &IQ; stanza addressed to the account or server entity hosting
<p>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 &lt;fin/&gt; tag to indicate that the query is completed.</p>
@ -337,7 +337,7 @@
<p>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 &lt;fin&gt; 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.</p>
</section3>
<section3 topic='Retrieving form fields' anchor='query-form'>
<p>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:</p>
<p>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:</p>
<example><![CDATA[
<iq type='get' id='form1'>
<query xmlns='urn:xmpp:mam:0'/>