The most typical address is that of a user's own bare JID, within which those messages sent to or from that user's account would generally automatically be stored by the server. The collection is ordered chronologically by the time each message was sent/received.

Servers that expose archive messages of sent/received messages on behalf of local users MUST expose these archives to the user on the user's bare JID.

A MUC service allowing MAM queries for a room MUST expose the MAM archive on the room's bare JID

If a 'with' field is present in the form, it contains a JID against which to match messages. The server MUST only return messages if they match the supplied JID. A message in a user's archive matches if the JID matches either the to or from of the message. An item in a MUC archive matches if the publisher of the item matches the JID; note that this should only be available to entities that would already have been allowed to know the publisher of the events (e.g. this could not be used by a visitor to a semi-anonymous MUC).

To allow querying for messages the user sent to themselves, the client needs to set the 'with' attribute to the account JID. In that case, the server MUST only return results where both the 'to' and 'from' match the bare JID (either as bare or by ignoring the resource), as otherwise every message in the archive would match.

If 'with' is omitted, the server MUST match all messages in the selected timespan with the query, regardless of the to/from addresses on each message.

If (and only if) the supplied JID is a bare JID (i.e. no resource is present), then the server SHOULD return messages if their bare to/from address for a user archive, or from address otherwise, would match it. For example, if the client supplies a 'with' of "juliet@capulet.lit" a query to their own archive would also match messages to or from "juliet@capulet.lit/balcony" and "juliet@capulet.lit/chamber".

The 'start' and 'end' fields, if provided, MUST contain timestamps formatted according to the DateTime profile defined in &xep0082;

The 'start' field is used to filter out messages before a certain date/time. If specified, a server MUST only return messages whose timestamp is equal to or later than the given timestamp.

If omitted, the server SHOULD assume the value of 'start' to be equal to the date/time of the earliest message stored in the archive.

Conversely, the 'end' field is used to exclude from the results messages after a certain point in time. If specified, a server MUST only return messages whose timestamp is equal to or earlier than the timestamp given in the 'end' field.

If omitted, the server SHOULD assume the value of 'end' to be equal to the date/time of the most recent message stored in the archive.

If the client has already seen some messages, it may choose to restrict its query to before and/or after messages it already knows about. This may be done through the 'before-id' and 'after-id' fields.

If the client already knows the UID of one or more messages it wants to fetch, it can use the 'ids' field:

If any UID requested by the client in any of the 'before-id', 'after-id' or 'ids' form fields is not present in the archive, the server MUST return an item-not-found error in response to the query.

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:

The server replies with all the form fields it supports in queries, which MUST include the mandatory fields specified in this document.

If the client understands any of the additional fields it MAY proceed to include any of them in subsequent queries. It is not required to include any or all of the supported fields in queries.

A special note about the 'ids' field: this field is of type 'list-multi' which typically is used to allow the client to select from a provided list of options. In this case the list of all possible ids MUST NOT be provided by the server, as it is likely to be extremely large. Instead the server MUST include a &xep0122; <validate/> element that signals the list is open to arbitrary values provided by the client.

As specified in &xep0068;, names of custom fields SHOULD use Clark notation to avoid conflicts with other extensions.

Note that as the 'with', 'start' and 'end' fields MUST be implemented by servers, clients are able to submit forms using combinations of only these fields without needing to first fetch the form from the server and the types of these fields MUST be 'jid-single', 'text-single' and 'text-single' respectively. A server MUST NOT rely on a client having first requested the form before submitting queries

If a client includes a form field that the server does not recognise, the server MUST respond with a 'feature-not-implemented' error.

A client or server will typically want to limit the number of results transmitted at a time, thereby breaking the result stream into smaller 'pages'. For this purpose a server MUST support &xep0059; and MUST support the paging mechanism defined therein. A client MAY include a <set/> element in its query.

For the purposes of this protocol, the UIDs used by RSM correspond with the UIDs of the stanzas stored in the archive.

To conserve resources, a server MAY place a reasonable limit on how many stanzas may be pushed to a client in one request. Whether or not the client query included a <set/> element, the server MAY simply return its limited results, modifying the <set/> element it returns appropriately.

The <first> and <last> elements specify the UID of the first and last returned results (not necessarily of all the messages that matched the query, if the results have been limited).

The RSM <count> element and the 'index' attribute on the RSM <first> element are optional, a server MAY include them, but a client MUST NOT depend on them being present. Please refer to the RSM specification for more information surrounding their meaning and use.

Having previously made a query that returned results limited by the server (as described above), a client can re-send the same request and receive the next 'page' of results. It does this by including a <set> element with its request, containing an <after/> with the UID of the last message it received from the previous query.

Note: There is no concept of an "open query", and servers MUST be prepared to receive arbitrary page requests at any time.

RSM does not define the behaviour of including both <before> and <after> in the same request. To retrieve a range of items between two known ids, use before-id and after-id in the query form instead.

If the UID contained within an <after> or <before> element is not present in the archive, the server MUST return an item-not-found error in response to the query.

When the results returned by the server are complete (that is: when they have not been limited by the maximum size of the result page (either as specified or enforced by the server)), the server MUST include a 'complete' attribute on the <fin> element, with a value of 'true'; this informs the client that it doesn't need to perform further paging to retreive the requested data. If it is not the last page of the result set, the server MUST either omit the 'complete' attribute, or give it a value of 'false'.

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.

To request the page at the end of the archive (i.e. the most recent messages), include just an empty <before/> element in the RSM part of the query. As defined by RSM, this will return the last page of the archive.

Within the returned page, all results are still in chronological order, that is, the first result you receive will be the oldest item in the page, and the last result you receive will be the last item in the archive.

When fetching a page, the client may prefer for the server to send the results within that page in reverse order. For example, if a client implements a user interface that automatically fetches older messages as a user scrolls backward, it may want to receive and display the newest messages first, instead of waiting for the whole page to be received.

A client wishing for a reversed page should include the <flip-page/> element in its query, like so:

It is important to note that flipping a page does not affect what results are returned in response to the query. It only affects the order in which they are transmitted from the server to the client.

A client that wishes to use flipped pages MUST ensure that the server advertises the 'urn:xmpp:mam:2#extended' feature.

A user archive is anticipated to provide the user with the ability to access their prior conversations. To this end, a server SHOULD include in a user archive all of the messages a user sends or receives of type 'normal' or 'chat' that contain a <body> element. A server SHOULD also include messages of type 'groupchat' that have a <body>, but where such history is accessible through another method (e.g. through an archive on the MUC JID), a server MAY exclude these from the archive. A server MAY include additional non-conversation messages. A server MAY include messages of type 'headline', but this is not generally suggested.

At a minimum, the server MUST store the <body> elements of a stanza. It is suggested that other elements that are used in a given deployment to supplement conversations (e.g. XHTML-IM payloads) are also stored. Other elements MAY be stored.

If a server supports mechanisms that multiply copies of a stanza (e.g. Carbons, or forking a stanza to a bare JID), it MUST store such a staza within a given archive only once, irrespective of multiple connected clients receiving copies

A MUC archives allows a user to view the conversation within a room. All messages sent to the room that contain a <body> element SHOULD be stored, as should subject change stanzas, apart from those messages that the room rejects.

A MUC archive MUST store each message only once (not, for example, every copy sent out to an occupant).

A MUC archive MUST NOT include 'private message' results (those sent directly between occupants, not shared in the room) in the results

A MUC archive MUST check that the user requesting the archive has the right to enter it at the time of the query and only allow access if so. In a members-only chat room, only owners, admins or members can query a room archive. In the case of open MUC rooms, the MUC archives can generally be accessed by any users (including those who have never entered the room) who do not have an affiliation of 'outcast', but a MUC archive MAY further limit access based on other criteria as part of the deployment policy. A MUC archive MAY, if it stores historical data about previous configuration states, limit the results returned to only those that the querying user would have been authorised to see at the time (e.g. it MAY limit the results to not include results while a user was an outcast).

When sending out the archives to a requesting client, the forwarded stanza MUST NOT have a 'to' attribute, and the 'from' MUST be the occupant JID of the sender of the archived message.

In the case of non-anonymous rooms or if the recipient of the MUC archive has the right to access the sender real JID at the time of the query, the archive message will use extended message information in an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with a 'jid' attribute specifying the occupant's full JID, as defined for non-anonymous room presence in &xep0045;. The archiving entity MUST strip any pre-existing <x> element from MUC messages (as MUC rooms are not required to do this).

This specification reserves the 'node' attribute of the <query> element for use with pubsub archives. Full details of using this protocol to query pubsub node archives are documented in [FIXME: number to be assigned to xep-pubsub-mam].