[Standards] XMPP Council Minutes 2018-08-01
lnj at kaidan.im
Sat Aug 11 17:46:29 UTC 2018
On Wed, 08 Aug 2018 10:39:52 -0500
Sam Whited <sam at samwhited.com> wrote:
> On Mon, Aug 6, 2018, at 10:25, Tedd Sterr wrote:
> > 3b) Proposed XMPP Extension: File Sharing Notifications -
> > https://xmpp.org/extensions/inbox/fsn.html
> > …
> > Sam: [on-list] (agree with Kev, but not sure if it should go to
> > Experimental)
> As it stands right now there are a few things that really concern me
> about this XEP. The only one really worth blocking for is the fact
> that this allows users to send file upload percentages as part of the
> chat state and I don't think this is something we want to encourage.
> Instead, it would make more sense to me for each file sending
> mechanism to have a way to send the total size of the file and allow
> clients to calculate the percent complete themselves. This makes it
> harder for a remote client to abuse the protocol (eg. to try and use
> it as a "time until completion" meter that counts down instead, or to
> be buggy and cause a meter to jump around on the remote client,
> making the user think it's their client that's having issues, etc.)
To solve this I think the best option would be to add a 'bytes-total'
attribute to at least the initial sending notification, because the most
commonly used protocols (HTTP File Upload/SIMS) only send a message
after the upload has already finished.
> Also, perhaps more importantly, this ties file percent completion to
> support on the remote client, so a local client wouldn't be able to
> support it consistently (some file transfers would have it, some
I agree with you on that, the progress shouldn't be OPTIONAL.
> 3b) Proposed XMPP Extension: File Sharing Notifications -
> Georg doesn't like that there's no enumeration of all possible FSN
> states, ...
I can add an enumeration for the three states (creating, uploading,
> nor an example of how to stop FSN, but likes the idea.
Well, currently the client should just recognise the incoming file and
should then end FSN. Of course this can lead to problems if the file
sharing protocol is not supported by the remote client. I can add an
On the XMPP meetup in Berlin some ideas to improve the current file
sharing with HTTP File Upload came up (thanks to Paul). If the progress
is transmitted in bytes and the http upload server is also serving
incomplete files, the remote client could already download parts of the
file while the file upload still has not finished. And everytime the
progress is updated the next part could be downloaded via. a range
request. This way HTTP File Upload 'transfers' could quite be speeded
up. Of course this is out of scope of FSN, but were an interesting thing
for HTTP File Upload and SIMS in combination with FSN.
More information about the Standards