I didn't assist to the Summit @ Brussels so I lack a lot of information. Having said that, What is JabberDisk? Can't we use XEP-129 and may be also XEP-135 for that goal? We are using XEP-129 for file sharing (in rooms) and since it's server based it should be possible to hook up a virus scanning solution. It is also possible to define users/entities allowed to get the file. So is JabberDisk == XEP-129? :)
-- Gato On 8/18/08 2:20 AM, "Yann Biancheri" <[EMAIL PROTECTED]> wrote: Hi everyone, I remember we spoke about "JabberDisk" at the last XMPP Summit in Brussels but I can't found any documentation on it in the xeps or Jabber wiki. We'd like to share images between multiple xmpp entities, and we have to check for viruses in the transfered file. As such, JabberDisk seems to be the way to go since it implies an intermediate server. The File Sharing and File Repository and Sharing xep seems to be good starting points but I was wondering if the action items for Jabber Disk has been performed or not. We can help documenting that approach if nothing has been done yet. - Yann If that could be of any help to someone here is a compilation of xeps related to file transfer/sharing XEP-0047: In-Band Bytestreams (IBB) : http://www.xmpp.org/extensions/xep-0047.html XEP-0065: SOCKS5 Bytestreams : http://www.xmpp.org/extensions/xep-0065.html XEP-0096: File Transfer : http://www.xmpp.org/extensions/xep-0096.html XEP-0129: WebDAV File Transfers : http://www.xmpp.org/extensions/xep-0129.html XEP-0135: File Sharing : http://www.xmpp.org/extensions/xep-0135.html XEP-0214: File Repository and Sharing: http://www.xmpp.org/extensions/xep-0214.html On 21 mars 08, at 23:56, Peter Saint-Andre wrote: > Finally catching up on email, in case you hadn't noticed. :) > > Here are the action items I see from the devcon... > > 1. Update XEP-0045 with security considerations regarding DoS, abuse, > nick spam, nick mimicking, etc. > > 2. Further investigate the idea of server reputations and querying > trusted peer servers regarding such information > > 3. Gain consensus on roster synchronization > > 4. Define session hush and session pauses feature (probably do not > belong in XEP-0198 since they could be used over BOSH as well) > > 5. Define fast reconnect / session resumption feature > > 6. Document "JabberDisk" approach to file transfer > > 7. Better document use of SRV records for components > > 8. Define alt link for receiving Atom notifications via pubsub > > 9. Add OpenID field to XEP-0154 > > Anything else? > > /psa > > Peter Saint-Andre wrote: >> Peter Saint-Andre wrote: >>> The XSF held a productive developer conference in Brussels over >>> the last >>> few days. I will write up the minutes tomorrow while flying back >>> to the >>> States and post them as soon as possible. >> >> Here's what I wrote on the plane... >> >> ****** >> >> XMPP DevCon #4 >> When: February 24-25, 2008Where: Brussels, BelgiumLogs: >> http://logs.jabber.org/[EMAIL PROTECTED]/2008-02-24.html >> >> http://logs.jabber.org/[EMAIL PROTECTED]/2008-02-25.htmlScribe >> : >> Peter Saint-Andre1.0 Deployment issues, with a focus spam and abuse >> 1.1 Issues >> >> - currently, most spam/abuse happens in Multi-User Chat rooms >> - JID mimicking common (e.g., add space) >> - service-wide nick reservation enables denial of service >> - rate limiting is necessary (handled now by room bots) >> - nick spam (really long roomnicks) >> - presence spam seen in the wild (frequent presence changes) >> - add best practices to XEP-0045- sending a large number of messages >> to a victim also seen >> - privacy lists can help (block all not in roster) >> - even then you can have subscription request spam >> - do we want centralized blacklists/whitelists (RBL)? >> - consensus is that RBL would introduce central failure point- >> better: >> ask peer server(s) that you trust >> - things will be worse once botnets gain control of legitimate JIDs >> - need to be clear on the architecture (client-server) >> - concentrate on the server side (more trusted, easier to update) >> - try to avoid netsplits and alternative federations (islands OK) - >> build a reputation system between servers? (not for end users) >> >> 1.2 Possible recommendations >> >> - need better monitoring of MUC rooms >> - Digg-like service for rating XMPP servers? >> - protocol for reporting abuse and escalating >> -> there is DoS potential here! >> - better traffic shaping / monitoring in server codebases >> - share contact information for operators >> - incremental trust of new servers that come onto the network >> - ask server "buddies" about other domains on the network >> - network status report a la BGP? >> >> 2.0 Mobile optimizations >> >> 2.1 What people have done or suggested >> >> - fast reconnection >> - pipelining of stream negotiation exchanges (Tony Finch) >> - don't retrieve roster (but this doesn't really help) >> - compression >> - BOSH (for mobile, is it better, the same, or worse than TCP?) >> - "session pause" feature >> - traffic filtering / profiles for mobile >> >> 2.2 Issues >> >> - bandwidth usage >> - latency of communication >> - power consumption >> ==> this is the major issue! >> - some operators block TCP >> - TCP timeouts are determined by service provider >> - need ability to pause or "quiet" a session >> - what do mobile users want? >> - presence-enabled contact list >> - typically a sub-list (not the complete roster) >> - do not receive presence from everyone >> - manage via privacy lists? >> - instant messaging >> - probably alerts and notifications (pubsub) >> - possibly Jingle calls (e.g., via wifi) >> - need way to negotiate how frequently device will wake up? >> - above all, maximize time in powersave mode! >> - for what reasons will the device be brought out of powersave? >> - IM from contact >> - phone call from contact >> - selected presence? (buddy pounce) >> - when brought out of powersave, send other queued stanzas >> - this is not battery-intensive because now you are awake >> - can this be done merely with privacy lists? >> - may need better handling of messages (e.g., Advanced Message >> Processing = XEP-0079) >> - define heuristics that say what to send when >> - TLS compression is good (DEFLATE) -- use it if at all possible >> - assume that TLS will succeed (it fails only if there is a >> misconfiguration) >> - stream feature for this? >> - buffer / queue stanzas while in pause or quiet mode >> >> 2.3 Recommendations / action items >> >> - outside expert says: we're on the right track (TCP better than UDP, >> DEFLATE is good, incremental approach, etc.) >> - document pipelining of XML sent during stream negotiation (per Tony >> Finch's email) >> - do we need an additional filtering protocol? >> - consensus: no >> - see how far we can get with privacy lists and best practices >> - define features for: >> - pausing a session (no interruptions) >> - quieting a session (selected interruptions OK) >> - do these belong in BOSH, in XEP-0198, privacy lists, or >> somewhere else? >> >> 3. XML synchronization / remote eventing >> >> 3.1 Motivations >> >> - whiteboarding >> - shared editing >> - collaborative data objects >> - more generally: DOM synchronization (for agents / wizards etc.) >> - even more general: perform operations on non-XML objects >> - question: is this in scope for XMPP?? >> >> 3.2 Issues >> >> - two modes (Fabio Forno) >> - session mode (e.g., whiteboarding) >> - sessionless (e.g., DOM events) >> - sharing events is easy >> - conflict resolution is hard >> >> 3.3 Conclusions >> >> Two models: >> 1. "event stream synchronization" -- it may be worthwhile to design >> a simple protocol extension for this >> 2. "object synchronization" -- this is hard and probably should be >> out of scope for the XSF >> >> 4.0 File transfer >> >> 4.1 Issues >> >> - the discussion continues -- why?? >> - currently no mandatory-to-implement (MTI) technology >> - result: poor interoperability >> - many different requirements, environments, and scenarios >> - no "one ring to bind them all" >> - need better fallback mechanisms >> - latency issues >> - do we really need to stream? >> - NAT traversal challenges >> - discussed pros and cons of multiple transport methods: >> - IBB >> - SOCK5 Bytestreams >> - "JabberDisk" -- SOCKS5 to server, HTTP GET to retrieve >> - jdisk could be generalized? (e.g., IBB to server) >> - WebDAV to upload, HTTP GET to retrieve >> - ICE-TCP >> - Torrent >> - avian transport :) >> - so many options -- how to manage? >> - also discussed pros and cons of negotiation methods: >> - Stream Initiation, a.k.a. SI (XEP-0095/XEP-0096) >> - support exists >> - no counter-offers >> - settle on a single negotiation method? >> - Jingle (XEP-0166) >> - counter-offers possible >> - flexible >> - scary >> - but scariness comes from ICE, not Jingle state machine >> - discover support via caps >> - also a migration path in SI (if caps not supported)? >> >> 4.2 Conclusions >> >> >> - IBB is the only transport method guaranteed to work >> - we've already punched a hole in the firewall via XMPP! >> - make this MTI but lowest-priority fallback >> - other transport methods are valuable in different situations >> - require support for HTTP GET on receiver side (for JDisk/WebDAV >> scenarios) >> - Pavel and Peter to document JabberDisk approach >> - Jingle is the more flexible negotiation method, so let's use it >> - but we need a migration path from SI >> >> 5.0 Jingle >> >> 5.1 Counter-offer process >> >> - content-modify is not well specified >> - agreement to use it only to change direction >> - therefore need new verb for content-replace >> - use this to counter-offer transport >> - reject content-replace if change of application type >> - file transfer application type must specify direction >> - typical case: file offer from sender to receiver >> - also: file request from receiver to sender >> - changing from offer to request (or vice-versa) is OK for content- >> replace >> >> 5.2 reasoncode and reasontext >> >> - this is ugly!!! >> - specify child elements instead for more robust error reporting >> >> 6.0 Other Topics >> >> 6.1 Distributed MUC >> >> - this is interesting, but do we really want/need to solve it? >> - treat your local MUC service as a proxy to others? >> - jointly manage .xmpp. TLD? >> - SRV records for failover? >> - e.g., if conference.jabber.org goes down then reconnect to >> chat.xmpp.org >> - list only the authorized proxies that you sync with >> - recommended approach for now >> >> 6.2 SRV records >> >> - RFC 3920 is not clear on necessity of SRV records for components >> - _xmpp-server._tcp.conference.jabber.org -> athena.jabber.org >> - we need to document and encourage this in rfc3920bis, XEP-0220, >> etc. >> >> 6.3 Machine-to-machine communication >> >> - need better support for automation resources (e.g., negative >> priorities) >> - use RAP (or something similar) for smarter routing at the server? >> >> 6.4 Component protocol >> >> - support ability for component to: >> - create a user session >> - get presence >> - get roster >> - layer these features on top of recent XEP-0225 >> >> 6.5 Web integration / HTTP / SSO / OAuth / OpenID >> >> - not a great deal of interest, it seems >> - but there is interest in the HTTP world >> - XMPP as a window onto web-based services >> - great source of content / eventing for XMPP-based services >> - need way to put OpenID in XMPP user profile (XEP-0154) >> - list JID at OpenID provider page >> - <link type='???' href='xmpp:[EMAIL PROTECTED]'/> >> - use XMPP to federate HTTP silos >> >> 6.6 MUC++ >> >> - MEP = MUC Eventing via PubSub >> - Mingle = MUC room as control channel for multi-user Jingle >> - don't modify MUC services unless necessary: just use bots? >> - share presence with the room to receive caps >> - Collabora and Wimba interested in the Mingle idea >> - futher conversations to occur after the devcon >> >> 6.7 Message archiving >> >> - XEP-0136 is OK -- let's finish it >> - optional IMAP interface to archives? >> - split up XEP-0136 so that scary encryption stuff goes in a >> separate spec >> >> 6.8 Application platform >> >> - why define long complicated XML protocols for every feature under >> the sun? >> - they don't define every possible application as an HTML extension >> via W3C! >> - why not use something like JavaScript or Flash in the XMPP world? >> - long, interesting discussion -- but out of scope for XSF >> - interested developers to pursue after the devcon >> >> END > > > -- > Peter Saint-Andre > https://stpeter.im/ >
