[Standards] File sharing xep proposal

Jefry Lagrange jefry.reyes at gmail.com
Tue Nov 6 17:14:03 UTC 2012

Hello Matthew, thanks for the feedback.

On 11/05/2012 11:06 PM, Matthew Wild wrote:
> Hi Jefry,
> On 6 November 2012 01:19, Jefry Lagrange<jefry.reyes at gmail.com>  wrote:
>> Hello,
>> I've been working for quite some time in a protocol extension to allow file
>> sharing. I have a (some-what) working prototype of its implementation.
> Great to hear! I can think of a million-and-one uses for such a
> protocol, and I'm sure I'm not alone.
>> The prototype is available at Gajim's plugin repository:
>> http://hg.gajim.org/gajim-plugins
> and running code is always good :)
> I read very quickly through (it's 4am after all...), and it seems
> pretty sensible. Any comments I have are minor, and I think it's
> perfectly fine to submit it as it is.
> A few of my comments...
> It seems like it might be possible to make the directory listing XML
> somewhat more compact than it currently is. For example just listing
> files with no metadata could simply be:
>     <file name="foo.txt"/>
>     <file name="bar.txt"/>
> which seems a lot simpler than the nested XML elements in the example.
> Metadata can be child elements of<file/>  because although every file
> has a name, metadata may vary and will almost certainly want to be
> extended in some cases.
Yeah, about that... I wanted to reuse current extensions whenever 
possible. This format for <file> is the same in xep096 and xep234. I see 
what you are saying, it is indeed more compact and saving bandwidth in a 
situation where big stanzas are sent, is very important.

At first I considered the dataforms as they are used in xep0135, but 
they were too big to be used efficiently. I definitely favor making this 
as compact as possible.
> I'm not sure how necessary it is to require the leading '/' prefix, it
> seems natural to omit it if I just have a flat list of files. And then
> 'foo/bar.txt' is perfectly fine when I don't, so it seems like it
> could be dropped without much problem.
Does it look weird? The only reason why I made it a requirement to use a 
leading '/' was to make it possible to distinguish between asking for 
more information on a file or directory, and searching for a file. When 
searching files there should not be a "/" prefix. I don't know of any 
other way of doing this.

Dataforms would be very good for searching, since they support regular 
expressions. However, as I said before, they can get pretty big.

I would like to listen to some ideas about how search could be 
accomplished in a nice way.
> The security note about access control being implemented on servers
> doesn't make complete sense. Files are shared by a specific resource,
> so each resource can enforce its own access controls... and different
> resources won't necessarily be sharing the same sets of files. A
> logged in client generally already has the roster, which is probably
> the main access control advantage that the server could offer anyway.

Ah... I didn't make it clear. What I was thinking about was not about 
individual file permissions, it was about preventing an user to see any 
files at all. Blocking an user from file sharing, would require 
agreement across the different resources so they can agree about no 
sharing files with that particular user.

I know realize that this is more of an implementation issue than a 
security issue, I should move it to "implementation notes", because it 
is up to the implementers if they want to add a feature to block an user 
from all file sharing.

> Anyway, good work... and I look forward to it being approved soon, and
> perhaps implementing it myself :)
> Regards,
> Matthew


More information about the Standards mailing list