[Standards] XEP-0047: IBB

Fabio Forno fabio.forno at gmail.com
Fri Feb 19 10:05:55 UTC 2010


On Wed, Feb 17, 2010 at 11:37 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> If I understand your comment correctly, I would change the text as follows:
>

fine, just a doubt about SHOULD or MAY temporarily suspend...  I'm not
sure it is the general desired behavior, but just for some
applications like long living bytestreams. What happens in other cases
when a file jingle transfer fails while going on? I think the general
case is re-negotiating the jingle session and send the remaining part
of the file.

I'd suggest to retry in case of timeout in the IQ too (if we have an
already established ibb, resending the IQ for a while is the sane
thing imho).


> ***
>
> 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/
>
>
>
>



-- 
Fabio Forno,
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com
==========================
Ooros srl
jabber id: ff at jabber.bluendo.com



More information about the Standards mailing list