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