[Standards] How-To documents? (was Re: [Summit] whiteboard notes)
On 10/26/2012 11:29 PM, bear wrote: (Moving this to standards. Including the summit notes for reference). Hi, Looking over these notes, I get the impression many issues are already solved with one or more XEPs. But even within our community many of these solutions are not generally known or how these XEPs can interact is not clear. How would that be for a fresh implementer, looking for libraries and standards to quickly build an application? So shouldn't we take some time to write a bunch of How-To documents describing ways to attack common problems. Issues that come to my mind are: - Shared BOSH/websockets c.q. cross-tab and cross-device state sharing - XMPP over unreliable and low bandwidth connections - Setting up a to HTTP/websockets restricted client Probably there are more topics to cover. A good writeup of the discussion at the summit should probably cover the first two topics. Unfortunately I won't be able to do that, though I might be able to pull on the last one. Any opinions / idea's / additions on this? Winfried Here are the notes I took - any errors or gaps are mine, please add/correct if you spot them: Thursday, 2012/10/25 1. Informational XEP on acking 198 - stream management bosh 124 message receipts 184 stanza acking AMP - 79 (deprecate?) how big to keep a queue which XEP does what? when to use which tools 2. batch size to controllable in BOSH 3. BOSH cleanup 4. 198 w/websocket BOSH 1. BOSH vs WebSocket 2. XMPP over WebSocket 3. batch / buffer size 4. General BOSH cleanup - pipelining, - what happens when two requests are received with the same RID - terminate all sessions when close request is made? 5. Session attachment - prebinding - oauth in HTTP - SASL XMPP == tunneling - no channel binding - 206: header with token body sasl/ /body 6. Shared BOSH - won't need it once we have shared web workers - do this at BOSH layer of XMPP layer? - subscribe to existing - roster versioning? carbons? Friday, 2012/10/27 Shared BOSH - client state at application level messaging carbons pubsub - sub from all resources muc - join from all (shared nicks) - issues: latency - cache on the server with SAM (Stanza Archiving Mechanism) - lost state: muc rooms, pub sub, transport registrations, etc - autojoin - joined rooms - store in a roster? 1. PEP Versioning 2. best practices for saving state JSON - object formats - map e.g. pubsub to S.S.E (generalize: content-type) BuddyCloud - API Server https://buddycloud.org/wiki/Buddycloud_HTTP_API#Content_Types https://github.com/buddycloud/buddycloud-http-api - wire format vs objects in code - socket.io like experience - stanza.io Mobile bandwidth better, latency = issue data still costly always-on xmpp not workable push notification to wake up best practices for considering a session to be dead (XEP-198 resumption) negotiate keepalives EMN = OMA spec for SMS wakeup wakeup (with IMAP id to ??? server) client tells server to use wakeup don't send me presence (SIFT? or Google Queue-ish)
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.
