[Standards] DevCon report

[Peter Saint-Andre]

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/devcon@conference.jabber.org/2008-02-24.html
> 
> http://logs.jabber.org/devcon@conference.jabber.org/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:myjid at domain.tld'/>
> - 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20080227/fb8d6b4a/attachment-0001.bin