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

[Peter Saint-Andre]

Marcus Lundblad wrote:
> 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.

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 
supports 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.

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?

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://pidgin.im/pipermail/devel/attachments/20080708/b2ebb0fe/attachment-0002.bin>