Ticket #6183 (in-band bytestreams filetransfers on XMPP)

[Marcus Lundblad]

tis 2008-07-01 klockan 13:40 -0600 skrev Peter Saint-Andre:
> Marcus Lundblad wrote:
> > FYI
> > 
> > I've started on support for using XEP-0047 (IBB) as a fallback method
> > for file transfers on XMPP.
> > Right now it almost works as a "standalone" method (ie. when disabling
> > support for socks5), it can complete a file transfer when everything
> > goes well. 
> 
> Great!
> 
> > It doesn't quite yet handle cancellation.
> > Also it can't yet "take over" when socks5 bytestreams fail.
> 
> It's not fully clear to me what you mean by cancellation and takeover. 
> Could you clarify? I want to make sure the protocol addresses your concerns.
> 
Hi.

I have been working more on implementing support for XEP-0047 when using
XEP-0096 for file transfers.
But I just realized it seems that the receiver can just select one value
for the "stream-method" in the reply.
What I would like, would be if there was a way for the receiver to say
that it could do socks5 (preferred) or if that fails in-band bytestream.
So that if the receiver gets a timeout setting up socks5 it will send an
<iq/> with type "error" and the initiator would then initiate an IBB
sesion, or if the initiator gets a timeout it would go ahead and offer
IBB.
Unfortunatly the current XEP for file transfers can't really handle this
as far as I can see.

The solutions I could see would be:

1) Blindly assume that IBB is an acceptable fallback option and rely on
the receiver to return an "error" <iq/> if it doesn't handle IBB.

2) Extend the reply of the file transfer offer in XEP-0096 to specify a
fallback option in addition to the <value/> child of the <field/>
element in the reply.

Or, I'll have to start thinking about XEP-0234... :)

//Marcus

> > And it is not exactly a speed deemon :)
> 
> No, it's not. But it's intended to be the method of last resort. :)
> 
> /psa
>