[Standards] XEP-0047: IBB

Peter Saint-Andre 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
> 
> Agreed.
> 
>> - No recovery at all if the SID is missing
> 
> Agreed.
> 
>> 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
'cancel'.

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:

http://xmpp.org/extensions/tmp/xep-0047-1.3.html

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



-------------- 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/7f90f943/attachment.bin>


More information about the Standards mailing list