[Standards] File sharing xep proposal
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. The prototype is available at Gajim's plugin repository: http://hg.gajim.org/gajim-plugins It doesn't do a lot, but it can share files between computers. Although the code is in alpha stage everyone who is brave enough is welcomed to try it. I have attached a draft of the protocol extension. I would like some feedback on it. If it doesn't looks too bad, I would like to present it to the council by the end of the week. Cheers, ?xml version='1.0' encoding='UTF-8'? !DOCTYPE xep SYSTEM 'xep.dtd' [ !ENTITY % ents SYSTEM 'xep.ent' %ents; ] ?xml-stylesheet type='text/xsl' href='xep.xsl'? xep header titleFile Information Sharing/title abstractThis document specifies a simple extension to existing protocols that allows an entity to request information about files./abstract LEGALNOTICE; number/number statusProtoXEP/status typeStandards Track/type sigStandards/sig approverCouncil/approver dependencies specXMPP Core/spec specXEP-0234/spec specXEP-0059/spec specXEP-0265/spec /dependencies supersedes specXEP-0135/spec /supersedes shortnamefis/shortname author firstnameJefry/firstname surnameLagrange/surname emailjefry.re...@gmail.com/email jidj.lagra...@jabber.org/jid jidj.lagra...@gajim.org/jid /author revision version0.0.1/version date2012-10-14/date initialsjl/initials remarkFirst draft/remark /revision /header section1 topic='Introduction' anchor='intro' pXMPP extensions provide ways of transferring files between peers (such as xep0234; and xep0096;). However, file transfer is currently limited to needing that the transfer be initiated by the hosting entity. The xep0234; extension, provides for a way to request files, but it requires the requesting entity to have information about the file being requested, so that it can be uniquely identified. /p pThis documents defines an extension which allows the request of information of files being offered by a hosting entity so they can later be requested in a file transfer; If the requesting entity is interested in the file./p pIRC users have been able to bypass the limitations of the protocol by using bots that provide information of files and initiate transfer on command. A major downside of this method is that not every user is capable of sharing its files. The aim of this document is to provide a similar functionality while making it easier for users to offer and request information about files. /p pMicrosoft's MSN proprietary IM client, used to provide similar functionality using Sharing Folders, but this was replaced by Windows Live SkyDrive /p /section1 section1 topic='Requirements' anchor='reqs' ol liEnable a requesting entity to traverse the shared directory of an offering entity (REQUIRED)/li liEnable a requesting entity to get detailed information about files. (REQUIRED)/li liEnable a requesting entity to search files hosted by an offering entity.(OPTIONAL)/li liAllow the use of MUCs to share information about files among the users.(OPTIONAL)/li !--liAllow the use of Pub/Sub service to search files (OPTIONAL)/li -- /ol /section1 section1 topic='Assumptions' anchor='assump' !-- Maybe make this into a list -- p This protocol assumes the existence of a shared directory (either virtual or physical), whose root can be accessed by /. The hosting entity must not advertise empty directories. The hosting entity is responsible of maintaining the structure of that directory (such as not allowing two files with the same name and preventing cycles within directories). The hosting entity is in no way required to present the same shared directory to different requesters./p /section1 section1 topic='Getting Information About Files ' anchor='disco' section2 topic='Traversing Files' anchor='traver' pIf a requesting entity wishes to traverse the shared folder of an offering entity. It can do so by querying the root directory as it is shown in the following example:/p example caption='Requester queries the root of the shared folder' ![CDATA[ iq type='get' from='jul...@capulet.com/chamber' to='ro...@montague.net/home' id='1234' match request directory/ /request /match /iq ]] /example p If the offering entity has files to share, it MUST respond with the root-level files of its shared folder. Files and directories at the root level MUST not be the child of any directory tag. In order to save bandwidth, the offering entity MAY omit all the children of the file tag except the name which is required and MUST always be present. /p pThe file tag has the same attributes as defined in xep0096;. The name attribute is required and must be included in every response. The size attribute is only required when
Re: [Standards] File sharing xep proposal
Hi Jefry, On 6 November 2012 01:19, Jefry Lagrange jefry.re...@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. 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. 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. Anyway, good work... and I look forward to it being approved soon, and perhaps implementing it myself :) Regards, Matthew
