moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 10:12:19 -05:00
Code Issues Releases Wiki Activity

permissions / queue full

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1291 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-10-05 22:56:05 +00:00
parent ea9dd25861
commit 3a984255c8
1 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
xep-0160.xml
View File

@ -56,6 +56,7 @@
<ol>
<li>Sender generates XMPP message stanza <note>This document does not discuss IQ or presence stanzas, handling of which is described in <cite>RFC 3920</cite> and <cite>RFC 3921</cite>.</note> for delivery to a recipient such as an IM user or other node, where the 'to' address is of the form &lt;node@domain&gt; or &lt;node@domain/resource&gt; (see <cite>RFC 3921</cite> for rules regarding server handling of such XMPP message stanzas).</li>
<li>Recipient's server determines that the intended recipient has no available resources that have specified non-negative presence priority. <note>As specified in <cite>RFC 3920</cite>, available resources that have specified a negative presence priority shall never receive message stanzas addressed to &lt;node@domain&gt;.</note></li>
<li>Recipient's server determines that if the server can store offline messages on behalf of the intended recipient; if not (e.g., because the recipient's offline message queue is full), the server returns a &unavailable; error to the sender.</li>
<li>Recipient's server does not return a &unavailable; error but instead stores the message stanza for later delivery.</li>
<li>When the recipient next sends non-negative available presence to the server, the server delivers the message to the resource that has sent that presence. (Alternatively, the server may support &xep0013;, although that functionality is not described herein.)</li>
</ol>
@ -70,7 +71,8 @@
</body>
</message>
]]></example>
<p>Next, the recipient's server determines if there are any available resources that have sent non-negative presence priority. If there are, the server immediately delivers the message stanza to the resource that it determines to be most available (based on its own algorithm). If there are not, the server stores the message for later delivery.</p>
<p>Next, the recipient's server determines if there are any available resources that have sent non-negative presence priority. If there are, the server immediately delivers the message stanza to the resource that it determines to be most available (based on its own algorithm).</p>
<p>Next, the recipient's server determines if offline messages can be stored on behalf of the intended recipient. If not (e.g., because the recipient's offline message queue is full), the server returns a &unavailable; error to the sender. If so, the server stores the message for later delivery.</p>
<p>Now the recipient authenticates with the server and sends initial presence (with a non-negative priority) to the server.</p>
<example caption='Recipient Becomes Available'><![CDATA[
<presence from='juliet@capulet.com/balcony'>