[Standards] XEP-0047: IBB

Fabio Forno fabio.forno at gmail.com
Wed Feb 17 16:51:01 UTC 2010

On Wed, Feb 17, 2010 at 4:25 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> ***
> I think it needs to be more specific about the error types, as you
> suggest. So something like this:
> ***
> 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
> <item-not-found/> with a type of 'cancel' or 'modify',
> <unexpected-request/> with a type of 'cancel' or 'modify', or
> <bad-request/> with a type of 'cancel' or 'modify'. If the stanza error
> is of type 'auth' or 'cancel', the sender MUST close the bytestream as
> described under Closing the Bytestream; if the stanza error is of type
> 'continue', 'modify', or 'wait' the sender SHOULD 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; however, the
> recipient MAY close the bytestream if the sender attempts to send the
> same data packet too many times (in which case the stanza error
> condition MUST be <policy-violation/> with a type of 'cancel').
> ***
> However, I don't think that text is quite complete, because we might say
> more about how a client recovers from these errors. For example, how
> could the recipient handle the situation in which the session ID is
> unknown? Perhaps there's no good reason to expect that a client could
> recover from such errors. Feedback from implementers would be appreciated.

In fact I'm mumbling over the possible errors:
- in real cases the most common error is an <iq/> lost for which we
receive an error from our server (e.g. the case of a S2S connection
taking too much time to reopen), and in this case the recipient is not
involved at all in the process and the sender can try to recover by
re-sending the stanza
- IDs out of sequence o packets with bad data are something which is
very uncommon on an xmlstream and when it happens the only sane
recovery is restarting the stream
- No recovery at all if the SID is missing

After this I'm stepping back on the option of always closing the
stream when some error is detected by the recipient.



More information about the Standards mailing list