[Standards] File sharing xep proposal

Matthew Wild mwild1 at gmail.com
Wed Nov 7 03:37:39 UTC 2012


On 6 November 2012 17:14, Jefry Lagrange <jefry.reyes at gmail.com> wrote:
> On 11/05/2012 11:06 PM, Matthew Wild wrote:
>> 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.

Aha, now I understand. Something I missed last night... you need to
add namespaces to the elements in the examples to show this :)

>> 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.

I don't know about "weird", but my first reaction was that it seemed
to be an unnecessary restriction.

> 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.

To perform search I would probably use a different iq request
completely, and a <search> command. You could make data forms
optional, when there are multiple things to search on (for example a
database of music may allow me to search on metadata). The results
don't necessarily have to be supplied in dataforms also though (it
wouldn't be the only protocol that does this).

>> 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.

Ok, I understand. In this case I think the note should be a security
consideration that just warns implementers that they should support
access control to protect users. Suggesting that servers should get
involved without actually providing a protocol for that seems wrong
(and such a protocol could probably be a XEP in itself if necessary).

In reality I don't think it is too much of a problem. If I have an
open share and just one person I don't like, I would probably block
them using XEP-0191 or (shudder) XEP-0016.

Regards,
Matthew



More information about the Standards mailing list