<remark>Added use case for retrieving number of messages; defined registar considerations more completely.</remark>
</revision>
<revision>
<version>1.1</version>
<date>2004-01-22</date>
<initials>psa</initials>
<remark>Editorial revisions.</remark>
</revision>
<revision>
<version>1.0</version>
<date>2003-09-09</date>
<initials>psa</initials>
<remark>Per a vote of the Jabber Council, advanced status to Draft.</remark>
</revision>
<revision>
<version>0.8</version>
<date>2003-08-25</date>
<initials>psa</initials>
<remark>More changes to address Council feedback: removed bandwidth rationale in requirements; added protocol flow section; adjusted semantics for node values (opaque, but dictionary ordering allowed). Also added <fetch/> and <purge/> elements.</remark>
</revision>
<revision>
<version>0.7</version>
<date>2003-08-21</date>
<initials>psa</initials>
<remark>Changes to address Council feedback: added error codes; enhanced the security considerations; clarified the nature of the node IDs and removed the protocol URI string (leaving only the timestamp).</remark>
<remark>Added reference to XEP-0082; changed timestamp format to use milliseconds rather than ten-thousandths of a second; made several small editorial changes throughout.</remark>
<remark>Major overhaul: clarified requirements, incorporated disco, simplified and updated the protocol, specified syntax and semantics for nodes, defined business rules, and added XML schema.</remark>
</revision>
<revision>
<version>0.3</version>
<date>2002-10-02</date>
<initials>cak</initials>
<remark>Reworked to exclude XDBID performace hack, thereby maximizing palatability. Removed all changes made by psa.</remark>
</revision>
<revision>
<version>0.2</version>
<date>2002-10-02</date>
<initials>psa</initials>
<remark>Changed type and added information about scope.</remark>
</revision>
<revision>
<version>0.1</version>
<date>2002-01-11</date>
<initials>cak</initials>
<remark>Initial version</remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>Although not required to do so by &rfc3920; and &rfc3921;, many existing Jabber/XMPP instant messaging servers will store messages received while a user is offline and deliver them when the user is next online. Such messages are commonly called "offline messages". The current means of retrieving one's offline messages is simple: one sends available presence to the server and, as a consequence, the server sends a one-time "flood" of all the messages that have been stored while one was offline. This simplification has the following deficiencies:</p>
<ol>
<li><p>It can be overwhelming, which is undesirable for the vacationer or heavy user. Many individuals upon returning to work from a weeklong vacation spend the first few hours wading through the dozens, even hundreds, of emails that they received during their absence. Unlucky, however, is this user who then logs onto their Jabber server and is bombarded by hundreds of instant messages, possibly in scores of popup dialogs, simultaneously. Should their client crash, they have lost all communication that occurred while they were away.</p></li>
<li><p>It can be difficult to integrate with web-based email clients, which is undesirable for some portals. Several large portals are currently trying to blur the distinction between IM and email -- providing both through one web interface. With offline retrieval semantics so vastly different between the two, this is quite difficult.</p></li>
</ol>
<p>What is needed is a flexible semantic for offline message handling, similar to POP3 in the email world (see &rfc1939;). This would enable the wireless user to view header information for all offline messages and select only those from their boss and important clients for viewing. It would enable the vacationer to read and delete their messages one at a time, minimizing the possibility of losing all correspondence. And it would provide for seamless integration with existing web-based email clients.</p>
<p>In particular, such a protocol should support the following use cases:</p>
<ol>
<li>Client determines server support for this protocol.</li>
<li>Client requests number of messages.</li>
<li>Client requests message "header" information (thereby choosing flexible offline message retrieval as opposed to old-fashioned "flood" mode).</li>
<li>Client retrieves specific messages.</li>
<li>Client removes specific messages.</li>
<li>Client retrieves all messages.</li>
<li>Client removes all messages.</li>
</ol>
</section1>
<section1topic='Use Cases'anchor='usecases'>
<section2topic='Discovering Server Support'anchor='discover'>
<p>If the server supports this protocol, it MUST return a <feature/> element in the disco result with the 'var' attribute set to the namespace name for this protocol: 'http://jabber.org/protocol/offline'.</p>
</section2>
<section2topic='Requesting Number of Messages'anchor='request-number'>
<p><cite>RFC 1939</cite> includes a feature (the "STAT" command) that enables a user to determine how many messages are waiting to be retrieved (without retrieving all of the headers). Such a feature would be helpful in Jabber/XMPP as well, especially if the client is constrained with regard to storage capacity or available bandwidth.</p>
<p>In order to determine the number of messages in the offline message queue, the user sends a disco#info request without a 'to' address (i.e., implicitly to the user himself) and with the disco node specified as 'http://jabber.org/protocol/offline':</p>
<examplecaption='User Requests Information About Offline Message Node'><