The XMPP Blog

Google has announced the 2007 Summer of Code projects, and the XSF projects are as follows: Bidirectional-streams Over Synchronous HTTP (BOSH) Support in gloox (Student: Matthew James Wild, Mentor: Jakob Schröter) Data Form Designer Suite for XMPP (Student: Tobias Markmann, Mentor: Kevin Smith) Encrypted Sessions Test Suite and Implementation (Student: Brendan Taylor, Mentor: Yann Le Boulanger) Extended Stanza Addressing and Other XEPs in ejabberd (Student: Bernardo Antonio de la Ossa Pérez, Mentor: Mickaël Rémond) Jingle Audio/Video in Gajim (Student: Tomasz Melcer, Mentor: Yann Le Boulanger) Personal Eventing in Openfire (Student: Armando Diaz-Jagucki, Mentor: Gaston Dombiak) Let’s start coding!  [Read More]

Although the XMPP Standards Foundation runs its own standards process and publishes a dedicated specification series for XMPP extensions, we continue to work within the Internet Engineering Task Force on relevant specifications, which we mirror at xmpp.org for convenient access. Lately we have updated several of the RFCs and Internet-Drafts we are working on within the IETF: draft-saintandre-rfc4622bis this document corrects several errors in RFC 4622, which defines the xmpp: URI scheme (a handy diff from RFC 4622 is here) [draft-saintandre-jabberid](http: www.xmpp.org internet-drafts draft-saintandre-jabberid-05.html) this document defines the Jabber-ID email header, which enables you to specify your XMPP address in the email messages you send draft-saintandre-xmpp-simple this document, which describes interworking between XMPP and SIMPLE for basic IM and presence, shows our continued commitment to open communication (an informal last call is in progress on the discussion list of the IETF’s SIMPLE WG) draft-ietf-sieve-notify-xmpp this document, an official work item of the IETF’s Sieve WG, defines how to generate XMPP notifications for receipt of new email (and more) using the Sieve email filtering language And look for some relatively slight modifications to rfc3920bis and rfc3921bis soon.  [Read More]

Members of the IETF’s SIMPLE Working Group recently analyzed the scalability of SIP/SIMPLE technologies with respect to sharing presence between domains. Because their work provides a helpful baseline for comparing presence technologies, we decided to perform a similar analysis for XMPP. The results should be of interest to any large enterprise, ISP, or carrier that is contemplating deployment of presence-based services. Consider some of the relevant results for bandwidth usage between two presence domains:  [Read More]

Following in the grand tradition of XEP-0076 (implementation in the Psi client announced today), XEP-0132, XEP-0148, and XEP-0183, today we published XEP-0207: XMPP Eventing via Pubsub (XEP). This new “XEP XEP” is perhaps the most significant XMPP extension protocol yet published by the XMPP Standards Foundation, since it provides a solid, extensible foundation for any further payloads we might want to send over the network. Read the spec for complete details.  [Read More]

The XMPP Standards Foundation will once again be participating in the Google Summer of Code for 2007. What is a standards organization doing in the Summer of Code? Well, the Extensible Messaging and Presence Protocol (XMPP) emerged from the Jabber open-source community and we still have many active open-source projects. Plus as previously mentioned our community is a cohesive blend of open standards, commercial organizations, and open-source developers.  [Read More]

Freedom is one of our core values in the Jabber/XMPP community. The focus on freedom goes back to Jeremie Miller, who invented the base of our technologies in 1998 as a way for people to connect over the Internet without the silos and restrictions enforced by consumer IM services. Over the years that sense of freedom has broadened and deepened. Consider: Our community has centered on Internet protocols (not a given open-source codebase) in part to give developers the freedom to use whatever license they want: free source, open source, freeware, shareware, commercial, or any combination thereof. Our protocols are as free as the air, which means anyone may implement them without asking permission or worrying about patents. Our protocols are pure XML, which means developers may extend the protocols for their own custom functionality. While we standardize XMPP extensions that are of more general interest, developers have the freedom to make their own extensions and not standardize them through the XSF if they don’t want to. As previously mentioned, all of our discussion venues and processes are completely open and transparent, giving any individual the freedom to participate. Our technologies are designed to enable organizations to connect their XMPP servers for inter-domain federation if desired, but they also have the freedom to run a server behind the firewall without connecting to other domains. Individuals who use Jabber/XMPP technologies for instant messaging still have the fundamental freedom of conversation that Jeremie envisioned back in 1998. So freedom is more than just a pleasant word or “value statement” for us – it is a way of life and a key part of everything we are working to achieve.  [Read More]

At the XMPP Summit on Monday we held a rare in-person meeting of the XMPP Council, since we had four of the five Council members in attendance. Among other things the Council issued a Last Call for comments on XEP-0174: Link-Local Messaging. This technology, which enables real-time messaging in the absence of a server, was pioneered by Apple in an early version of their iChat client. It has since been adopted in several open-source instant messaging clients and is now also widely used in the One Laptop Per Child project.  [Read More]

Yesterday the IETF announced that draft-saintandre-xmpp-urn has been approved by the IESG for publication as an informational RFC. What this means for us is that the XSF (specifically the XMPP Registrar) will control its own “tree” of Uniform Resource Names to issue for use in XMPP Extension Protocols, as specified in Section 4 of XEP-0053. This is good because URNs are more stable than the URIs (such as “http://jabber.org/protocol/muc") that we’ve been using for XML namespaces in our protocols. Although we lose the ability to copy and paste such a URI into a browser and find information about the relevant protocol, it’s easy enough to search for a string like “urn:xmpp:chatneg” and find the relevant specification. So the slight loss in convenience is offset by the improved permanence of our XML namespaces. Besides, all the other standards development organizations are using URNs, so why not us? :-)  [Read More]

Over the weekend, members of the XMPP Standards Foundation and the Jabber developer community participated in FOSDEM 2007 (one of the world’s premier conferences for developers of free and open-source software) and also held a smaller “XMPP Summit” to discuss high-priority issues related to our technology. I think it’s safe to say that the weekend was a smashing success. Our developer room at FOSDEM hosted a full schedule of talks and was often standing room only. Topics included virtual presence, Jingle, telephony integration, mobile applications, server and client architecture, transporting XMPP over HTTP connections, and hacking XMPP applications with the Twisted Python library. I also gave a talk in the main track on secure communications (video footage is here), in which I discussed our recent security work and announced our partnership with NLnet to make end-to-end encryption a reality on our network.  [Read More]

Because the XSF is a standards development organization, we strive to honor standards developed by other organizations. To that end, we recently updated the web pages at www.xmpp.org (including our specification series) to comply with XHTML 1.0. If you find a page with an “xhtml 1.0 compliant” link at the bottom but the page does not validate, please report the error to webmaster at xmpp.org.  [Read More]