[Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing

Tedd Sterr teddsterr at outlook.com
Mon Feb 26 14:44:41 UTC 2018

I see your point now - I was looking at XEP-0329 (File Information Sharing), where the shared files are requested using a full path; while your issue is that XEP-0234 (Jingle File Transfer) only wants a single file name (without path).

So, presumably, the files are advertised via 0329 (with paths), then when a requester decides which file they want, they ask (with path) for its info - the info includes filename (no path) & hash, which can then be used to initiate the 0234 transfer (?)

If you have two files with the same filename and hash, but in different paths, does it actualy matter which one you send (they're essentially identical) ...or the date stamp chould be included as well (at which point, maybe a UUID is less work.)

XEP-0358 (Publishing Available Jingle Sessions) could provide a more appropriate mechanism (with IDs!), though it might be wasteful for advertising large numbers of files. Not that it couldn't be extended..

From: Standards <standards-bounces at xmpp.org> on behalf of Goffi <goffi at goffi.org>
Sent: 26 February 2018 13:54
To: XMPP Standards
Subject: Re: [Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing

Hi Tedd,

thanks for your feedback

Le dimanche 25 février 2018, 21:19:16 CET Tedd Sterr a écrit :

> The requestor should ask for the full path to the file, not the bare
> filename, so as long as you don't have two files with the same name in
> the same directory, there shouldn't be a conflict. Treat the node name
> as an opaque identifier for the file, so a request for a bare filename
> simply won't match any of the shared files (except in the case where the
> file is shared without any containing directory, but this should still
> be the only file with that name.)

Well the XEP states that "/" SHOULD NOT be used in name (XEP-0234 §5 and
§12), so I'm not sure that putting the path there is a good idea. If so it
would simplify things, but wording should be changed.

> 'path/filename' should be a unique identifier, otherwise how do you know
> which they are requesting? Also, if you can give all files a unique ID,
> that unique ID could just as easily be the hash value itself.

I may use versioning in the future, so path/filename may not be unique,
that's why I would like to use UUID.

> > 4) if there are several file conresponding to a file request (e.g. only
> > name is given), what should we do ? Return the first one or send a
> > "conflict" stanza error?
> As above; this shouldn't happen - you should not offer to share two files
> with the same path+filename.

My question is if we have only the filename or the hash (even if payload
will be the same with single hash, metadata like name or date can differ)

> The XEP hints at the possibility of requesting a file by name only (sans
> path), but only when this will be unique; I suggest the request MUST
> include the path to avoid any confusion.

But there is no way to include the path at the moment.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180226/70a4d481/attachment.html>

More information about the Standards mailing list