My apologies for the bad line breaks etc. I hadn't slept for 23 hours when I sent that and didn't check the formatting before I hit Send. :(
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
smime.p7s
Description: S/MIME Cryptographic Signature
