Chris Mullins for Council 2006

History

I've been a Member of the Jabber Software Foundation since April of 2003, and have consistently worked towards open standards.

Current Software Development Activities

I am the Chief Engineer at Coversant, where I'm responsible for the technical aspects of the SoapBox Platform.

These aspects include the SoapBox Framework, which is a commercial XMPP SDK. I've been involved in all stages of development of this Framework, from the network stack (socket and XML handling) through the Object Oriented layers, all the way through the client interfaces. I have personally implemented dozens of Jeps in this Sdk, including complex Jeps such as Publish-Subscribe. This SDK runs on Windows, Windows Mobile (such as all those cool SmartPhones), and on Linux.

I also continue to work on the SoapBox Server, which is a commercial XMPP Server. Like the SoapBox Framework, I've been involved in all stages of developing the server. My background in scalable network application combined with x64 and IA64 support have helped the SoapBox Server exceed 250k simultanious users connected to a single box. The SoapBox Server has dozens of Jeps implemented, including complex ones such as Publish-Subscribe and Multi-User Chat. Many of the JEP implementations were personally implemented by me, or where code reviewed by me.

There are other XMPP related projects I'm involved in, but they're all currently very hush-hush! :)

I author a technical .NET Blog that's updated whenever I can think of something interesting to write about. This blog can be found at: http://www.coversant.net/blogs/cmullins

Qualifications

As a founder of Coversant, I've got signifigant personal interest riding on the success of the XMPP protocol and by extension the JSF. The more involved I become in the protocol, the more effectivly I'm able to act act as a Technology Evangalist (which is part of my official role Coversant) pushing XMPP into new markets, new niches, and new customers.

My background is as a Software Engineer and Solutions Architect. Large scale, high performance network applications is where I've been focused the last several years. Software which I've designed or written has been installed by more than 5 million people. I'm experienced with Protocol Design and Networking Technology, and have written software ranging from embedded systems all the way up through today's largest Itanium servers.

With Coversant, I've been heavily involved in XMPP and Jabber for a number of years, and have implemented the XMPP RFC's as well as a number of JEPS.

In Jabber land, I've implemented the following JEPS on both the client and server side:

• JEP-0004, Data Forms
• JEP-0012, Last Activity
• JEP-0022, Message Events
• JEP-0030, Discovery
• JEP-0045, Multi-User Chat (portions of)
• JEP-0047, In-Band byte Streams (portions of)
• JEP-0048, Bookmark Storage
• JEP-0049, Private XML Storage
• JEP-0050, Ad-Hoc Commands
• JEP-0054, VCard
• JEP-0055, Search
• JEP-0060, Publish-Subscribe
• JEP-0066, Out-Of-Band
• JEP-0077, In-Band Registration
• JEP-0078, Non-SASL Authentication
• JEP-0082, Date and Time Profiles
• JEP-0085, Chat State Notifications
• JEP-0086, Error Conditions (XMPP <-> Jabber Mappings)
• JEP-0090, Entity Time
• JEP-0091, Delayed Delivery (portions of)
• JEP-0092, Version
• JEP-0095, Stream Initiations (portions of)
• JEP-0106, JID Escaping
• JEP-0115, Entity Capabilities
• JEP-0153, VCard Avatars

My full resume can be found online at http://www.coversant.net/downloads/ChrisPublicResume.pdf

Sixth Council Priorities

One of the better aspects of my job is that I get to see how a wide range of customers put XMPP to use. Interestingly, the same set problems seem to frequently arise. Addressing these problems, as well as continuing to push the Protocol to meet new needs is the primary reason I'm running for the Jabber Council.

In no particular order, I see these problems (and there's no surprises here to anyone): - Setting up and Configuring an XMPP server is more difficult than it should be. There are a few reasons for this, although SRV records seem to be the main culprit. Administrators don't know what they are and DNS Providers don't support them.

• End to End encryption isn't being used today, which means something needs to change. I'm not quite sure what that something is, but clearly improvement is needed.
• Certificates aren't frequently used, and when they are used (as the Interoperability Event pointed out) we still can't to S2S SASL in an effective way. We need this to be better.
• Partially implemented and/or incompatiable solutions.

Another priority is to see XMPP stop trying to play catch-up with the major consumer networks. I would like to see us focus on innovative features that the consumer networks can't or won't provide. Examples of this are the huge range of possabilities offered by the PEP infrastructure, the Jingle work being done, and the Asterick integrations that we're seeing. With the next version of Exchange providing a PBX, and with LCS out there, we have to make sure we stay ahead in features or risk the commercial markets being lost to the giants. The drive into the US Military, with their adoption of XMPP is also going to require new features and changes that we, as a standards body, need to keep up with.

I would also like to see the formal adoption of a Certification and Test Suite. The fragmentation of XMPP hurts all the players, and any time someone downloads a new client or server that's incompatiable with other implementations, MSN wins a new customer. That just can't continue.

Lastly, a set of simply understood user standards for clients and server based on features is needed. This could be as simple as "Level 1 (basic chat)", "Level 2 (advanced and encrypted chat)", "Level 3 (conferencing)" or a more complicated matrix. The JSF has already put together some basic JEPS along this line, but it's still too complex and the integration throughout the site isn't there.

Contact

I can be reached via XMPP at cmullins@jabber.org, or via email at cmullins@coversant.net.