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

minor clarifications

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3230 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2009-06-05 22:50:33 +00:00
parent ef82d12a29
commit 79a98f8e56
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-0047.xml
View File

@ -192,8 +192,8 @@
]]></example> ]]></example>
<p>The sender need not wait for these acknowledgements before sending further stanzas. However, it is RECOMMENDED that the sender does wait in order to minimize possible rate-limiting penalties.</p> <p>The sender need not wait for these acknowledgements before sending further stanzas. However, it is RECOMMENDED that the sender does wait in order to minimize possible rate-limiting penalties.</p>
<p>It is possible that delivery of the stanza might fail, e.g. because the recipient has gone offline or because a server-to-server link has gone down). In this case the entity that detects the error shall return an appropriate XMPP stanza eror, such as &recipient; or &timeout;. Upon receiving notice that delivery of a data packet has failed, the sender MUST consider the bytestream to be closed and invalid.</p> <p>It is possible that delivery of the stanza might fail, e.g. because the recipient has gone offline or because a server-to-server link has gone down). In this case the entity that detects the error shall return an appropriate XMPP stanza eror, such as &recipient; or &timeout;. Upon receiving notice that delivery of a data packet has failed, the sender MUST consider the bytestream to be closed and invalid.</p>
<p>It is also possible that the recipient might detect an error with the data packet, e.g. because the session ID is unknown, because the sequence number has already been used, or because the data is not formatted in accordance with Section 4 of <cite>RFC 4648</cite>. In this case the recipient shall return an appropriate XMPP stanza error, such as &notfound;, &unexpected; or &badrequest;. Upon receiving notice that a data packet is cannot be processed by the recipient, the sender SHOULD consider the bytestream to be closed and invalid but MAY attempt to correct the error and re-send the offending data packet using the same sequence number (the recipient MUST NOT consider a sequence number to have been used until the data packet has been successfully processed).</p> <p>It is also possible that the recipient might detect an error with the data packet, e.g. because the session ID is unknown, because the sequence number has already been used, or because the data is not formatted in accordance with Section 4 of <cite>RFC 4648</cite>. In this case the recipient shall return an appropriate XMPP stanza error, such as &notfound;, &unexpected; or &badrequest;. Upon receiving notice that a data packet cannot be processed by the recipient, the sender SHOULD close the bytestream as described under <link rel='#close'>Closing the Bytestream</link> but MAY attempt to correct the error and re-send the offending data packet using the same sequence number (the recipient MUST NOT consider a sequence number to have been used until the data packet has been successfully processed).</p>
<p>Data packets MUST be processed in the order they are received. If an out-of-sequence packet is received for a particular bytestream (determined by checking the 'seq' attribute), then this indicates that a packet has been lost. The recipient MUST NOT process the data of such an out-of-sequence packet, nor any that follow it within the same bytestream; instead, the recipient MUST consider the bytestream invalid and SHOULD close the bytestream as described in the next section.</p> <p>Data packets MUST be processed in the order they are received. If an out-of-sequence packet is received for a particular bytestream (determined by checking the 'seq' attribute), then this indicates that a packet has been lost. The recipient MUST NOT process the data of such an out-of-sequence packet, nor any that follow it within the same bytestream; instead, the recipient MUST close the bytestream as described in the next section.</p>
</section2> </section2>
<section2 topic='Closing the Bytestream' anchor='close'> <section2 topic='Closing the Bytestream' anchor='close'>