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

[Marcus Lundblad]

tis 2008-07-08 klockan 19:15 -0600 skrev Peter Saint-Andre:

> > 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.
> 
> Nope, that's one reason why we've been working on the Jingle approach.
> 
> > 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.
> am
> That's a possible fallback, but it would be good to do that only if you 
> know (via service discovery or entity capabilities) that the other party 
> supports IBB.
> 

Yeah, I guess announcing XEP-0047 support and checking if the receiver
announces it, and in that case flag IBB as an option, at the moment the
way it's done in libpurple there is a datatype JabberSIXfer that is
associated to all XMPP-based file transfers. This has a field
"stream_methods" that is a bitmask flag with values, currently for
socks5 and IBB. Currently it is set according to the response. So in
this case there would be an additional check if the receiver announces
XEP-0047 then add IBB to this.
Now if the receiver doesn't understand the IBB <open/> stanza in this
context it should return an error <iq/> and the sender would cancel the
transfer.

I'll try it and see how it works.

> > 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.
> 
> I think that's less likely to be widely supported.
> 
> > Or, I'll have to start thinking about XEP-0234... :)
> 
> Yeah, I think that eventually all the cool kids will be using XEP-0234 
> for file transfer. The question is, when will "eventually" get here?
> 
Yep. This would eventually be the way to go, I assume.
XEP-0234 will get promoted from experimental along with the other
Jingle-related XEP:s, I guess?

Speaking of that, any news about the two remaining votes on XEP-0231?
Actually personally I'm running on a version of libpurple that sets the
namespace of the data tags without ":tmp:"... :)

//Marcus

> /psa
>