[Standards] Detecting an ended file transfer

Lance Stout lancestout at gmail.com
Mon Jul 29 16:03:52 UTC 2019

> 1) The transport method has a way of closing the stream. This exists for
> IBB, via the `<close>` element. It also exists for S5B, via closing the
> TCP connection.

Potential race condition since signaling and media are flowing in different planes.

You can’t be sure that the ‘done sending’ signal arrives after the peer has finished
receiving all of the data. IBB can do it, because signaling and data _are_ flowing
in the same plane, since it is in-band.

> 2) Counting the bytes until you receive as many bytes as promised by the
> file offer. This works if the non-mandatory `<size>` tag is present in
> the file offer.

That is the intended method, yes.

The size is listed as a SHOULD specifically to allow the case where the file being
sent is actually being generated on demand. In which case, the size wouldn’t
be known until the end. For any other case, the size would be known and would
be included.

> Could the XEP be amended to clarify how to do this? If 2) is the
> supposed method, could the XEP be changed so that the `<size>` tag is
> mandatory for offering a file?

Mandating the size in the offer wouldn’t suffice, as covered above. What would be
an appropriate change would be to have the checksum update include the final
size information (especially if it wasn’t included in the offer). The schema already
allows it, the XEP just needs to mention it. I honestly thought it already did, but this
particular situation did get overlooked.

I would consider such an update safe enough to keep in the current namespace.


More information about the Standards mailing list