[Standards] XEP-0047: IBB

Peter Saint-Andre stpeter at stpeter.im
Wed Feb 17 22:21:49 UTC 2010

On 2/17/10 9:51 AM, Fabio Forno wrote:
> 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

Yes, that seems to be the most common error.

> - 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.

By "stepping back on" do you mean "I think that the sender MUST close
the stream if it receives an error from the recipient related to a data
packet"? I'd be fine with that, but I wanted to check with people on
this list before recommending that behavior. All the errors I could
think of were fatal.


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100217/f495f0f6/attachment.bin>

More information about the Standards mailing list