From 79a98f8e5636372ec1a535697372c2c9cd744e74 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Fri, 5 Jun 2009 22:50:33 +0000 Subject: [PATCH] minor clarifications git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3230 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0047.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xep-0047.xml b/xep-0047.xml index afd35289..8e8b4375 100644 --- a/xep-0047.xml +++ b/xep-0047.xml @@ -192,8 +192,8 @@ ]]>

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.

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.

-

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 RFC 4648. In this case the recipient shall return an appropriate XMPP stanza error, such as ¬found;, &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).

-

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.

+

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 RFC 4648. In this case the recipient shall return an appropriate XMPP stanza error, such as ¬found;, &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 Closing the Bytestream 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).

+

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.