[Standards] IBB fallback in SI file transfer

Christian Schudt christian.schudt at gmx.de
Mon May 2 08:25:01 UTC 2016

I've had a brief discussion [1] about how the fallback to IBB works in SI filetransfer.
It's mentioned twice in XEP-0096 and it reads like a fallback to IBB is intended to work but it lacks a proper description about how it actually works.
My interpretion is this:
1. Initiator initiates file transfer offering S5B and IBB
2. Receiver chooses S5B
3. Initiator offers at least one stream host
4. Receiver can't connect to any host and returns <item-not-found/>
5. Initiator then opens an IBB session (same session id)
6. Receiver should always be prepared for the incoming IBB <open/>, because it's a mandatory technology.
Another interpretion is to start from 1. again after receiving <item-not-found/>, i.e. starting a new file transfer session, but this time only offering IBB. I think this probably leads to poor user experience due to a new file transfer request.
I know there's Jingle File Transfer, which specifies the fallback more precisely, but it's rarely implemented yet, experimental and doesn't help with the existing specification and implementations.
Do you have any thoughts about it?

-- Christian
[1]: https://community.igniterealtime.org/thread/58601

More information about the Standards mailing list