[Standards] Jingle File Transfer - Receiving party communicating success

Emmanuel Gil Peyrot linkmauve at linkmauve.fr
Wed May 3 15:34:20 UTC 2017

On Wed, May 03, 2017 at 11:17:17AM +0200, Daniel Gultsch wrote:
> Hi,


> the current Jingle File Transfer has two methods which can be used for the
> receiving party to announce that they successfully received a file.
> There is 'Ending the session' described in section 6.6 which terminates the
> session with a reason=success and there is section 8.1 which sends a
> session-info received.
> Both these methods are however optional.

The session ending is pretty much mandatory, but the wording of 6.6
doesn’t acknowledge that, with its “preferably”.  It is the only way
making sense, but only after having received every pending file in the
session and checking them all.

8.1 fills the gap of having received one specific file (content here)
in the session, with other ones still in flight.

> So if I wanted to - as a sender - make sure that the other party actually
> received the file I can't do that because I can't rely on any of the two to
> actually be send.

+1, we should change the wording.

> Therefore I suggest to make at least one of them a MUST for the receiver.
> I don't really care which one.

I would suggest both of them, as they carry different semantics.
<received/> could be made optional if it is about the last file being
transfered, mandatory otherwise.

> Conversations has always treated the session-terminate/success as a MUST
> and didn't end the file transfer if it wasn't received. (That's why when
> sending a file to Gajim it got 'stuck' at 100%)

This sounds sensible, and is also how I implemented it.

> cheers
> Daniel
> Stray observations:
> - There is too much 'optional' stuff in the XEP. The hashing stuff for
> example is virtually useless because I can't be sure the sender will send
> that.

I would like to introduce a way for the received to request a checksum,
of either the entire file or a range of it, but for some usecases it
may not be possible (for example when a client gets its data from a
pipe, it can read it once but not more).

> - The changelog from 0.16 mentions a remote-canditate which doesn't
> actually exists in XEP-260 which could be confusing.

Another issue is that the schema is not up to date, I will PR a fix


Emmanuel Gil Peyrot

More information about the Standards mailing list