[jdev] File Transfer Interoperability

[Sergei Golovan]

On 8/8/07, Justin Karneges <justin-keyword-jabber.093179 at affinix.com> wrote:
>
> If the sender offers a file and then cancels it before the receiver accepts,
> then S5B hasn't even started yet.  In other words, the sender hasn't sent the
> iq-set for the S5B open.  Therefore, there are no sockets to time out, and
> the receiver will wait forever.  Just like with IBB, just like with anything.
> It's an SI issue.

You're right. It's a file transfer request which takes a long time to
answer, and not an IBB one.

>
> If the sender cancels the file transfer immediately after the receiver
> accepts, then there is a chance that the sender may have started an IBB or
> S5B negotiation.  This is much less common than the SI problem, and I think a
> timeout in IBB here would be enough to solve this situation of bad luck.

Well, it would be better to clarify at least the most frequent stream
breaks. As for now, there's no way to break file transfer gracefully
(with error messgae which is shown to the peer).

>
> FWIW, S5B also doesn't specify any timeouts.  If the receiver goes offline
> instead of replying with an iq, then the sender will wait forever (and this

At least you'll notice that the receiver goes offline (not always
though). And in case of sender I think that it's impossible to find a
proper timeout. There always will be users complaining that they
replied too late.

> is the case today with Psi).  As you can see, endlessly waiting is not a
> feature of just IBB.  We generally don't specify timeouts in XEPs.  For

Tkabber now uses timeout only when waiting for ping request. But
probably it would be better to add some to file transfer part.

> example, how long should you wait for a vcard request to be answered?

Hm. Is it important? You show a notebook (or any other GUI, or nothing
if it's a text client) and some progressbar and fill in the fields on
answer comes. I don't think that vcard requires timeout at all.

-- 
Sergei Golovan