Ticket #6183 (in-band bytestreams filetransfers on XMPP)
stpeter at stpeter.im
Tue Jul 8 21:15:11 EDT 2008
Marcus Lundblad wrote:
> tis 2008-07-01 klockan 13:40 -0600 skrev Peter Saint-Andre:
>> Marcus Lundblad wrote:
>>> 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.
>>> 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.
> 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
> 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.
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
> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Devel