[Standards] DevCon report

Peter Saint-Andre stpeter at stpeter.im
Wed Feb 27 04:06:14 UTC 2008

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:

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
  - 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
  - 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

-------------- 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/20080226/cafd0eab/attachment.bin>

More information about the Standards mailing list