E N D
“” How much richer would it be if the network could extract more useful 'state' information about the device and/or user, especially if it is enriched with embedded sensors... "phone on charge", "user is on a Bluetooth headset", "battery low", "at location xyz", "moving in a way that looks like it's on train", "in a darkened room" and so on.... . “” • Dean Bubley 2008
XMPP - Extensible Real-Time Services Research Seminar for Dept. Communications and Networking (TKK) Matti Vesterinen 11.1.2008 Note: Slide notes contain more info!
agenda • Protocol basics • History, standardisation • & current implementations • Extensible Messaging and Presence Protocol • Near future • Potential • Other protocols • Q&A
XML stream • <stream> • <presence> • <show/> • </presence> • <message to='foo'> • <body/> • </message> • <iq to='bar'> • <query/> • </iq> • [ ... ] • </stream> stanza
<?xml version='1.0'?> • <stream:stream • from='example.com' • id='++TR84Sm6A3hnt3Q065SnAbbk3Y=' • to='juliet@example.com' • version='1.0' • xml:lang='en' • xmlns='jabber:client' • xmlns:stream='http://etherx.jabber.org/streams'> Server response open stream • <?xml version='1.0'?> • <stream:stream • from='juliet@example.com' • to='example.com' • version='1.0' • xml:lang='en' • xmlns='jabber:client' • xmlns:stream='http://etherx.jabber.org/streams'> Client initiates a stream to server
close stream • </stream:stream> • </stream:stream> Either entity may close the stream Other entity will reply
<presence/> initial presence I’m now available
presence • <presence> • <show>away</show> • </presence> • <presence from='juliet@example.com/balcony' • to='romeo@example.net'> • <show>away</show> • </presence> Client updates presence to away Contact receives the update
<iq to='juliet@example.com/balcony‘ • type='result' • id='roster_1'> • <query xmlns='jabber:iq:roster'> • <item jid='romeo@example.net‘ • name='Romeo' • subscription='both'> • <group>Friends</group> • </item> • <item jid='mercutio@example.org' • name='Mercutio' • subscription='from'/> • </query> • </iq> Server returns user’s roster iq:roster • <iq from='juliet@example.com/balcony' • type='get‘ • id='roster_1'> • <query xmlns='jabber:iq:roster'/> • </iq> Client queries for roster
<message • from='juliet@example.com/balcony' • to='romeo@example.net' • type='chat' • xml:lang='en'> • <body>How do you do ?</body> • </message>
not just presence & IM “” There are mission-critical XMPP deployments at most Wall Street banks, numerous major corporations, high-profile agencies of the U.S. federal government, and countless universities and small businesses worldwide. And the percentage of those organizations participating in the process of standardizing XMPP extensions continues to grow significantly, including contributions regarding voice and video integration from Google and on real-time language translation from the U.S. Department of Defense. “” Peter Saint-Andre, January 2007
extensibility – scalability • Protocol • XMPP Extension Protocols (XEPs): • publish-subscribe, multi-user chat, chat rooms, multimedia sessions (Jingle), link-local messaging, … • Services • Server components • Service discovery • Servers • Clustering a common solution but not part of XMPP • Server components help as well
IETF meetings near future potential real-time protocol for Internet
potential in mobile / Internet XMPP is a protocol that can deliver what Dean Bubley descriped in his 2008 prediction (1st slide) Contextual data fits well with Publish-Subscribe Android, mobile platform, has XMPP support Any kind of messages between devices Part of Google APIs and services (fixed to Google)
enablers • Open, standard protocol • Code libraries for your favorite language • Open source projects • Clients • Servers • Server components • Code libraries • Security • TLS, SASL, SPIM prevention, TCP stream, etc.
other protocols • SIP/SIMPLE • Voice drives SIP development • Implementation getting difficult due to enormous number of specifications • Bandwidth inefficient • NATs and firewall troubles (UDP, message based) • Proxy functionality (does not exist in XMPP) • Proprietary protocols • Fast development for specific needs • Need gateways to interconnect • One initial idea behind XMPP was to offer transparent comunication to other IM systems
conclusions • Open and standard protocol • Strong commitment to interoperability • Implementations drive standardisation • A lot of available extensions while easy to extend as needed • One client – server XML stream • TCP; http bindings available • Transfer any smallish content over IP • in real-time using XMPP