[Standards] XEP-0047: IBB
stpeter at stpeter.im
Wed Feb 17 22:37:16 UTC 2010
On 2/17/10 3:21 PM, Peter Saint-Andre wrote:
> 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.
If I understand your comment correctly, I would change the text as follows:
The sender of a data chunk need not wait for these acknowledgements
before sending further stanzas. However, it is RECOMMENDED that the
sender does wait in order to minimize the potential for rate-limiting
penalties or throttling.
It is possible that delivery of the stanza might fail, in which case the
sender's or recipient's server shall return an appropriate error:
1. Because the recipient has gone offline, the recipient's server
returns a <recipient-unavailable/> error with a type of 'wait'.
2. Because a server-to-server link has gone down, the sender's server
returns a <remote-server-timeout/> error with a type of 'wait'.
Upon receiving an error related to delivery, the sender SHOULD
temporarily suspend the stream but retry sending at a later time.
It is also possible that there is a problem with the data packet itself,
in which case the recipient shall return an appropriate error:
1. Because the session ID is unknown, the recipient returns an
<item-not-found/> error with a type of 'cancel'.
2. Because the sequence number has already been used, the recipient
returns an <unexpected-request/> error with a type of 'cancel'.
3. Because the data is not formatted in accordance with Section 4 of
RFC 4648, the recipient returns a <bad-request/> error with a type of
Upon receiving an error related to the data packet, the sender MUST
close the bytestream as described under Closing the Bytestream.
Because the changes are starting to become more significant, I've posted
an interim build here:
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards