Re: [Standards] File sharing xep proposal
This is certainly easier. If this extension gets rejected, I will definitely try to use xep-0135 instead. On 11/12/2012 04:14 AM, Sergey Dobrov wrote: So I suggest to keep XEP-0135 as is and just add ability to retrieve files via Jingle and to perform a search through ad-hoc commands. On 11/09/2012 03:26 PM, Sergey Dobrov wrote: On 11/09/2012 03:17 AM, Matthew Wild wrote: On 8 November 2012 18:41, Sergey Dobrov bin...@jrudevels.org wrote: On 11/09/2012 12:51 AM, Jefry Lagrange wrote: I have tried many different ways of making the protocol. The first time around, I modified xep0135 to include search capabilities. Someone told me, I think it was Matthew, that xep0135 abuses service discovery by using it too much. Also another thing that I noticed is that, data-forms make the xep0135 stanzas become really big, as they waste too much space. I actually don't understand hot is it possible to abuse service discovery. Maybe someone can explain? I believe the thread Jefry references is this one: http://mail.jabber.org/pipermail/standards/2011-November/025456.html ah, it seems that Jefrey was confused with the overload and abuse terms. So I still think that it would be better to keep files directories in the service discovery, just we need another way to do search queries. I believe that the same thing Matthew actually said in those thread. Regards, Matthew
Re: [Standards] File sharing xep proposal
On 11/16/2012 09:26 AM, Jefry Lagrange wrote: This is certainly easier. If this extension gets rejected, I will definitely try to use xep-0135 instead. Reuse existent standards is always easier, and it's definitely the best choice if these standards are suitable for the task. On 11/12/2012 04:14 AM, Sergey Dobrov wrote: So I suggest to keep XEP-0135 as is and just add ability to retrieve files via Jingle and to perform a search through ad-hoc commands. On 11/09/2012 03:26 PM, Sergey Dobrov wrote: On 11/09/2012 03:17 AM, Matthew Wild wrote: On 8 November 2012 18:41, Sergey Dobrov bin...@jrudevels.org wrote: On 11/09/2012 12:51 AM, Jefry Lagrange wrote: I have tried many different ways of making the protocol. The first time around, I modified xep0135 to include search capabilities. Someone told me, I think it was Matthew, that xep0135 abuses service discovery by using it too much. Also another thing that I noticed is that, data-forms make the xep0135 stanzas become really big, as they waste too much space. I actually don't understand hot is it possible to abuse service discovery. Maybe someone can explain? I believe the thread Jefry references is this one: http://mail.jabber.org/pipermail/standards/2011-November/025456.html ah, it seems that Jefrey was confused with the overload and abuse terms. So I still think that it would be better to keep files directories in the service discovery, just we need another way to do search queries. I believe that the same thing Matthew actually said in those thread. Regards, Matthew -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] File sharing xep proposal
So I suggest to keep XEP-0135 as is and just add ability to retrieve files via Jingle and to perform a search through ad-hoc commands. On 11/09/2012 03:26 PM, Sergey Dobrov wrote: On 11/09/2012 03:17 AM, Matthew Wild wrote: On 8 November 2012 18:41, Sergey Dobrov bin...@jrudevels.org wrote: On 11/09/2012 12:51 AM, Jefry Lagrange wrote: I have tried many different ways of making the protocol. The first time around, I modified xep0135 to include search capabilities. Someone told me, I think it was Matthew, that xep0135 abuses service discovery by using it too much. Also another thing that I noticed is that, data-forms make the xep0135 stanzas become really big, as they waste too much space. I actually don't understand hot is it possible to abuse service discovery. Maybe someone can explain? I believe the thread Jefry references is this one: http://mail.jabber.org/pipermail/standards/2011-November/025456.html ah, it seems that Jefrey was confused with the overload and abuse terms. So I still think that it would be better to keep files directories in the service discovery, just we need another way to do search queries. I believe that the same thing Matthew actually said in those thread. Regards, Matthew -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] File sharing xep proposal
On 11/09/2012 03:17 AM, Matthew Wild wrote: On 8 November 2012 18:41, Sergey Dobrov bin...@jrudevels.org wrote: On 11/09/2012 12:51 AM, Jefry Lagrange wrote: I have tried many different ways of making the protocol. The first time around, I modified xep0135 to include search capabilities. Someone told me, I think it was Matthew, that xep0135 abuses service discovery by using it too much. Also another thing that I noticed is that, data-forms make the xep0135 stanzas become really big, as they waste too much space. I actually don't understand hot is it possible to abuse service discovery. Maybe someone can explain? I believe the thread Jefry references is this one: http://mail.jabber.org/pipermail/standards/2011-November/025456.html ah, it seems that Jefrey was confused with the overload and abuse terms. So I still think that it would be better to keep files directories in the service discovery, just we need another way to do search queries. I believe that the same thing Matthew actually said in those thread. Regards, Matthew -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] File sharing xep proposal
Hello Jefry, Thank you for the HTML version you provided. The problem is very actual so thank you for your interest too. The first thing is that I think that the XEP-0135 (http://xmpp.org/extensions/xep-0135.html) way of browsing files is nicer because it reuses service discovery in very natural way. :) But the search compatibilities you provided in your XEP are nice too, but I think that queries should be improved though. The other thing I noticed is that you saying the the client MUST respond with the list of files if it was queried to do so. I don't think it's right because there are many conditions when client might decide not to do so: permissions control, bandwith control, etc. On 11/06/2012 08:19 AM, Jefry Lagrange 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. 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, -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] File sharing xep proposal
Hi On 11/08/2012 03:20 AM, Sergey Dobrov wrote: Hello Jefry, Thank you for the HTML version you provided. That wasn't me, thank Matthew for converting it and hosting it in his website. The problem is very actual so thank you for your interest too. The first thing is that I think that the XEP-0135 (http://xmpp.org/extensions/xep-0135.html) way of browsing files is nicer because it reuses service discovery in very natural way. :) But the search compatibilities you provided in your XEP are nice too, but I think that queries should be improved though. I have tried many different ways of making the protocol. The first time around, I modified xep0135 to include search capabilities. Someone told me, I think it was Matthew, that xep0135 abuses service discovery by using it too much. Also another thing that I noticed is that, data-forms make the xep0135 stanzas become really big, as they waste too much space. For those reasons, I decided to move away from xep0135 and instead of using dataforms, use the well known file stanzas as defined in xep096 and xep0234. In what way do you think that the queries could be improved? The other thing I noticed is that you saying the the client MUST respond with the list of files if it was queried to do so. I don't think it's right because there are many conditions when client might decide not to do so: permissions control, bandwith control, etc. Maybe it wasn't clear in the xep, I will check the writing. Basically if you don't have or want to share any files you just reply with a: match offer directory/ /offer /match Thanks for your feedback. On 11/06/2012 08:19 AM, Jefry Lagrange 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. 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,
Re: [Standards] File sharing xep proposal
On 11/09/2012 12:51 AM, Jefry Lagrange wrote: Hi I have tried many different ways of making the protocol. The first time around, I modified xep0135 to include search capabilities. Someone told me, I think it was Matthew, that xep0135 abuses service discovery by using it too much. Also another thing that I noticed is that, data-forms make the xep0135 stanzas become really big, as they waste too much space. I actually don't understand hot is it possible to abuse service discovery. Maybe someone can explain? Also, I don't think that forms waste much space. They bigger than SI's but not so much and they provide ability to be shown with existent form parsers. For those reasons, I decided to move away from xep0135 and instead of using dataforms, use the well known file stanzas as defined in xep096 and xep0234. In what way do you think that the queries could be improved? Specify the ways client should search files. For example, it can be something like wildcards for filenames or smth else. The other thing I noticed is that you saying the the client MUST respond with the list of files if it was queried to do so. I don't think it's right because there are many conditions when client might decide not to do so: permissions control, bandwith control, etc. Maybe it wasn't clear in the xep, I will check the writing. Basically if you don't have or want to share any files you just reply with a: match offer directory/ /offer /match I think that the better way is to define errors we can return because the empty set is not the same as error and errors have to be reported right way. Thanks for your feedback. On 11/06/2012 08:19 AM, Jefry Lagrange 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. 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, -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] File sharing xep proposal
On 8 November 2012 18:41, Sergey Dobrov bin...@jrudevels.org wrote: On 11/09/2012 12:51 AM, Jefry Lagrange wrote: I have tried many different ways of making the protocol. The first time around, I modified xep0135 to include search capabilities. Someone told me, I think it was Matthew, that xep0135 abuses service discovery by using it too much. Also another thing that I noticed is that, data-forms make the xep0135 stanzas become really big, as they waste too much space. I actually don't understand hot is it possible to abuse service discovery. Maybe someone can explain? I believe the thread Jefry references is this one: http://mail.jabber.org/pipermail/standards/2011-November/025456.html Regards, Matthew
Re: [Standards] File sharing xep proposal
Sorry, I don't know how to do that. Apparently there is a script for it gen.py, but I don't know how to use it and it finds some syntax errors that I don't know how to fix. On 11/07/2012 02:59 AM, Sergey Dobrov wrote: Could you attach rendered html version please? On 11/06/2012 08:19 AM, Jefry Lagrange 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. 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,
Re: [Standards] File sharing xep proposal
On Wed, Nov 7, 2012 at 5:13 PM, Jefry Lagrange jefry.re...@gmail.com ote: Sorry, I don't know how to do that. Apparently there is a script for it gen.py, but I don't know how to use it and it finds some syntax errors that I don't know how to fix. Should work just with: xsltproc xep.xsl yourprotoxep.xml yourprotoxep.html /K
Re: [Standards] File sharing xep proposal
On 7 November 2012 17:13, Jefry Lagrange jefry.re...@gmail.com wrote: Sorry, I don't know how to do that. Apparently there is a script for it gen.py, but I don't know how to use it and it finds some syntax errors that I don't know how to fix. I built a HTML version at: http://matthewwild.co.uk/uploads/xep-macth.html Change the extension to .xml to get the fixed XML (just a typo in some entities). Regards, Matthew
Re: [Standards] File sharing xep proposal
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 Lagrangejefry.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 offile/ 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 Thanks.
Re: [Standards] File sharing xep proposal
On 6 November 2012 17:14, Jefry Lagrange jefry.re...@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 offile/ 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
Re: [Standards] File sharing xep proposal
Could you attach rendered html version please? On 11/06/2012 08:19 AM, Jefry Lagrange 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. 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, -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
[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
