&xep0313; has an extensible form. This specification extends the extensible form with an extension which extends MAM to perform full text searching. A number of existing implementations of this extension exist - extending their existing extensions to confirm to the extension in this specification now it exists is intended to be trivial.
+Support for this protocol is advertised by the Service Discovery protocol defined in &xep0030; using a feature + of &ns;.
+Searching using full text is performed by the client supplying an additional text key, which if non-empty is used as input to a full text search of some form. The precise meaning of this field is left entirely implementation-defined at this time. Future revisions of this specification might impose additional constraints.
+A text input field of {&ns;}fulltext is hereby defined for the 'urn:xmpp:mam:2' FORM_TYPE, as conforming to the syntax defined in &xep0068;
+The precise matching of the supplied text string is left implementation-defined. Servers MAY use any full-text search engine. While this might mean that certain characters are deemed "special", clients are RECOMMENDED not to attempt any support for these, as they are unlikely to be portable between implementations. A conformant implementation of this protocol could be made, therefore, by accepting any string in the text field and returning nothing (or everything). Any server developer implementing this protocol in such a way MUST buy beers for everyone.
+Not sure this is needed at all.
+None?
+This XEP requires no interaction with &IANA;.
+Registration of the field pointing to this document.
+Guus der Kinderen nudged me into doing this.
+When initially run, a messaging client typically shows some list of contacts and chatrooms, and whether any new + messages are present in each.
+The current mechanism for achieving this UX involves a complete synchronization of the server-side archive, and is both + time-consuming and bandwidth-intensive. This specification proposes a solution to directly obtain such data from + the server.
+Moreover, the information gathered by the server to support this can be used in support of mobile push notifications.
+Nomenclature used for instant messages versus ancillary messages will need to be adjusted to make it consistent + with &xep0422; et al.
+Support for this protocol is advertised by the Service Discovery protocol defined in &xep0030; using a feature + of &ns;.
+The Inbox consists semantically of a list of conversations in order of last activity. Each conversation is + identified by a jid - for group chats this would be the chatroom, and for individual contacts this would be their + bare jid.
+Each Inbox entry includes a count of messages considered new, the last MAM stanza-id relating to this conversation, + and the last MAM result for this conversation, as defined by &xep0313;. In addition, a client-controlled boolean + marker can be used to indicate a manual "set unread" state.
+Finding more messages from this conversation can be achieved via a MAM query using with to specify the + conversation required.
+An &IQ; of type "get" is used, containing a single element <inbox/>, containing an optional RSM + filter as specified by &xep0059;. This will typically be sent only to the user's own bare jid. The server + responds with a sequence of &MESSAGE; stanzas, each containing an <entry/> element qualified by the + &ns; namespace with a number of attributes:
+The <entry/> element contains the latest instant message, if any, which is encapsulated as a + <result/> element as defined by &xep0313;. This contains collated fastenings if supported by the + server.
+After all entries required have been returned, the server then responds with an &IQ; result containing a + <fin/> element qualified by &ns;. This contains the RSM data, a total count of conversation + entries within the inbox, a count of conversations with unread messages, and a total count of unread messages.
+Any counter of unread SHOULD be accurate, however client implementors please note that due to heuristics + involved and other issues these counters can be inaccurate at times.
+A client MAY at any time set a conversation as marked by sending an &IQ; of type "set" containing something or + other. This causes the server to set the "marked" flag on a conversation. A client SHOULD display a marked + conversation in the same way as an unread conversation, and explicitly removed the marked flag when the + conversation is considered re-read.
+Removing a marked flag, even when the conversation is not currently marked, causes the unread counter for that + conversation to be set to zero.
+Servers MUST track which instant messages sent to clients remain unread.
+Let us assume a user has only two contacts they have exchanges messages with, and a single chatroom. Asking for their inbox is simple:
+The server responds with a list of conversations:
+After the list of messages, the server completes its response with a the reply to the original IQ.
+TODO - Hopefully roughly given by the examples.
+TODO
+This XEP requires no interaction with &IANA;.
+None.
+The author notes that this protocol is heavily based on the mod_inbox system of MongooseIM. In addition, Kevin Smith provided useful feedback which has shaped this specification.
+