Jabber XCP 5.4, the latest release of our real-time presence and messaging platform, is now generally available. The version 5.4 release includes support for XEP-0163: Personal Eventing via Pubsub (aka PEP) which I have discussed before. In addition to PEP support, Jabber XCP 5.4 also adds Pluggable Authentication Module (PAM) support for the Jabber Controller administrative interface, support for native compilers on all platforms and other features.

On June 25, 2008 at noon EDT, we are hosting a webinar XMPP - Adding Life to the Social Internet. Alex King, Founder of Crowd Favorite, Peter Saint-Andre, Chair of the XMPP Council and Joe Hildebrand, CTO of Jabber, Inc. will be joining me to discuss and demonstrate the use of XMPP, XMPP client libraries and PEP in social networking applications. If these topics are of interest, click here to register.

With each passing day, it becomes clearer that XMPP has become the standard way to add presence and messaging to Internet-based applications, services and communities.

Using Facebook Chat via Jabber is this week’s high profile evidence. The significance of this announcement goes much further than the impact on social networking services. For example, this analysis discusses the implications of the Facebook move for enterprise messaging and collaboration. XMPP Is Taking Over The World makes a strong numbers-based case for the enormous and rapidly-growing impact that XMPP has on the world of instant messaging. And the elegant and eloquent vision of XMPP’s role in cloud services shows that there is a lot more to the protocol than just IM.

So, if you want to add presence and/or messaging to an application and have millions of people be able to access it over the Internet, XMPP is the best way to do it. Don’t take my word for it, check out what the leading new online communities are using. Unless they have built a walled garden around a proprietary protocol, chances are, they have XMPP integrated into their services. Of course, I have a shameless plug recommendation if you’re looking for a highly scalable, presence and messaging platform that supports XMPP and other protocols and is used by many leading enterprises and online communities.

Given the evidence, the question has become: Why wouldn’t you use XMPP for presence and messaging?

Jabber, Inc. and the XMPP Community is now available as an archived presentation and a podcast.

In this webinar, Peter Saint-Andre, Chair of the XMPP Council, Oren Avissar, Director of Engineering, ooVoo and Joe Hildebrand, CTO, Jabber, Inc. join me in discussing:

• The history of Jabber/XMPP and Jabber, Inc.
• The XMPP Community and its governance process
• ooVoo’s presence-enabled multi-user video and voice communications service and other applications of Jabber XCP

If you would like to be notified of future webinars and other news and events, please fill out this subscription form.

This is big news; for Jabber, Avaya, our customers and everyone who is interested in presence and presence-enabling applications.

Here is an example use case of the technology in this announcement: imagine that your best friend at work has one XMPP device and one SIP device, both of which are online, publishing presence. When you subscribe to her with either protocol, you will see an aggregated view of her presence, including the presence all of her devices.

This is a unique solution providing aggregated presence for SIP/SIMPLE, XMPP and other protocols. Don’t confuse presence aggregation with federation. Aggregation collects presence information within a system, where it can be processed, filtered and published. Federation allows two or more systems to publish and subscribe to each others’ presence. Presence aggregation, particularly in multi-protocol, high-scale systems, is a much harder challenge than federation. Working together, Avaya and Jabber have met this challenge.

This announcement is another example of how presence is essential for unified communications, collaboration applications and real-time services. It also is proof positive of the fact that presence is useful for much more than instant messaging. In contrast to conceptual discussions on this blog discussing the types of applications driving demand for presence software and the critical requirements of presence platforms, this announcement is concrete - a real solution for real-world, real-time applications.

Participating in this solution has been of great value to Jabber in enhancing our multi-protocol technology and organizational knowledge. SIP is well established, particularly for applications incorporating digital telephony. Use of XMPP is growing rapidly the consumer, enterprise and government markets, with new presence-enabled applications and services based on the protocol being announced/uncovered on a weekly basis (read the hot scoop on new XMPP activities and applications here).

In case it isn’t clear, the value of presence is driven by Metcalfe’s Law. As more presence-enabled nodes (people, apps, devices, etc.) are added to a network, the value of the presence information grows exponentially. As there are several presence protocols, the only credible presence servers are those that are multi-protocol. It was challenging for Jabber, Inc. to become a multi-protocol presence server, but just being a presence server that only supports one protocol doesn’t cut it anymore.

Pedro Melo is wondering about negative presence priority:

But there are some road blocks ahead. The first one is that most clients out there don’t deal properly with negative priorities. If a buddy of mine only has negative priorities, my IM client must show him as offline. Most clients right now, don’t do that.
[Negative priority]

I agree with Pedro that it’s not clear how clients should render negative-priorty presence. This post outlines one possible approach. Just so that we have some concrete protocol to discuss, consider a PBX that injects the following presence on your behalf:

<presence from=“joe@example.com/phone“>
  <priority>-1</priority>
  <status>On the phone</status>
  <show>away</show>
  <c xmlns=“http://jabber.org/protocol/caps“
     hash=“sha-1“
     node=“http://jabber.com/bots/pbx“
     ver=“PwgGa/jZx9sUeueZsjT/xBlJfqo=“/>
  <reach xmlns=“http://jabber.org/protocol/reach“>
    <addr uri=“tel:+1-303-555-1212“/>
    <addr uri=“sip:joe@example.com“/>
  </reach>
</presence>

Let’s step through this bit by bit.

• Priority: -1, obviously, since that’s what we’re here to talk about. We would rather have messages be sent offline than come to this resource. It’s never the most available resource for this user.
• Status: We’re off-hook.
• Show: use the away icon. Which actual image should we show, though?
• Entity capabilities: a pointer to information about the software that sent the presence. The node URI is a semantically-relevant descriptor of the client, and the ver attribute is a hash of the features and other information about that client.
• Reach: how else can this device be reached? In this case, a POTS phone number and a SIP URI. This namespace is from the deferred XEP-0152, and is just here to give a little more flavor to the presence.

Assume that this is the only presence for this user at the moment. Now, imagine the client of a subscriber to this person, with a user interface that looks something like this:

This person is seeing me as offline for IM, and my phone is off-hook. There is an image for each of my negative-priority resources; presumably when I mouse over the image, something interesting will pop up, like “On the phone”. If I click on the image, I might be given options like “Call”, which could use the tel: URI in the reach section. One potential issue is what to do if there are too many negative-priority resources - that’s something for the UI designers to deal with, though.

But, how do we actually decide what image to show? There are several ways:

1. Hard-code a mapping between the (caps node, show) pair to a resource in the subscriber’s client. This would work, but is obviously limited for the future.
2. Hard-code a mapping between the (caps identity, show) pair of the device and a resource in the subscriber’s client. This is similarly limited.
3. Do an IQ to the publisher to ask what it’s current image is. With this one it’s hard to know when to cache, so scalability suffers.
4. Use one of the avatar XEPs (like 0153), and include an image reference in the presence. This doesn’t work because the avatar is for the identity of the person sending the presence, not for the software or device.
5. Create a new namespace that has a URL for the current presence icon. This would work just fine, and normal web caching would get us everything we need. It would increase the size of every presence stanza, though.
6. Add a couple of new fields to the XEP-0232 software information that comes along with the caps. There would be a field for each presence state that you care about, where the value of that field is a URL to an image.

This last approach is obviously the one I favor. The caps result would look like this:

<iq from=“joe@example.com/phone“
    to=“subscriber@example.com/work“
    id=“disco1“
    type=“result“>
  <query xmlns=“http://jabber.org/protocol/disco#info“
         node=“http://jabber.com/bots/pbx#PwgGa/jZx9sUeueZsjT/xBlJfqo=“>
    <identity category=“client“ type=“bot“ name=“PBX“/>
    <x xmlns=“jabber:x:data“ type=“result“>
      <field var=“FORM_TYPE“ type=“hidden“>
        <value>urn:xmpp:dataforms:softwareinfo</value>
      </field>
      <field var=“icon“>
        <value>http://jabber.com/pbx.png</value>
      </field>
      <field var=“icon_available“>
        <value>http://jabber.org/pbx_available.png</value>
      </field>
      <field var=“icon_away“>
        <value>http://jabber.org/pbx_away.png</value>
      </field>
    </x>
  </query>
</iq>

In this case, there is a general-purpose icon field, and then one icon_[show] field for each show that we will be sending. Whenever the subscriber gets a new negative-priority presence update, it looks in its caps cache, pulls out the field for the appropriate show, and pulls the image URL through an HTTP client that does caching (or does it’s own manual image caching). The image is scaled into the desired size, and displayed in the user interface. If these fields are added to XEP-0232, we should probably specify a desired image size, like 128×128 pixels.

We have started to see our customers and partners send negative presence, and are feeling the pain of client UI that doesn’t know how to deal with it. The first step for us is to figure out the correct protocol to deal with the UI issues. We’ll push this into MomentIM as soon after that as release cycles allow.

I’m in an excellent mood today. You probably don’t care, but you might care about an upcoming Jabber XCP enhancement that will make it easier for users to publish updates about their mood, location, what music they are listening to, etc.

XMPP is enhanced and extended through a standards process around XMPP Extension Protocols (XEPs). Jabber, Inc., has a long history of participation in the standards process (back to the days when XEPs were called JEPs) and through the years, support for many XEPs have been added to Jabber XCP, Jabber’s flagship XMPP server.

Our developers are at it again, adding support to Jabber XCP for XEP-0163: Personal Eventing via Pubsub, which should be of interest to anyone following the evolution and use of presence technology. XEP-0163 lets users send updates about anything to users on their rosters. Personal eventing lets people easily publish things about themselves - it doesn’t get any more user-centric than this! The updates are sent using the XMPP Publish-Subscribe functionality used in Jabber XCP’s InfoBroker and described in XEP-0060. One way to look at it is that XEP-0163 takes XEP-0060 functionality to a more personal level.

I was skeptical when we first started talking about adding this enhancement. The use cases in the XEP include sending updates on your current mood and what music you are listening to. I immediately understood the value of personal geolocation, a classical extended presence element, but mood? Why should Jabber’s customers at leading service providers, enterprises and government agencies care about such personal and subjective elements?

But then I had an epiphany: Presence is intrinsically personal and becomes more valuable as more details are added. Plus, personal subjective thoughts and feelings have major impacts on our world. Mood (sometimes veiled in more scientific words such as “sentiment” or “perception”) can determine the outcome of elections, move capital markets and have a major impact on the success of corporate, military and organizational initiatives. Things get really interesting when the extended presence details of many individuals are aggregated and analyzed. You probably don’t care what mood I’m in, but wouldn’t it be interesting to see the aggregated mood of everyone in your company or organization? How about the aggregated, real-time sentiment of voters, soldiers, traders or everyone in an online community, particularly if the information is up-to-date, accurate and made anonymous at the individual level?

The success of Twitter (which has XMPP in its architecture, BTW) and other similar services proves that personal eventing (in addition to presence, in general) is valued in social network settings. Service providers should be interested in the increased stickiness that personal eventing brings to their communities. Once users get used to seeing their friends’ moods, blog posts, activities, etc. they are more likely to stay in the communities which publish these details. The extension of social network technology to enterprise applications is in full swing, so by adding support for Personal Eventing via Pubsub to Jabber XCP, our extensible and highly scalable real-time presence and messaging platform will take the Power of Presence to a more personal and valuable level. The customers we’ve talked to about PEP have some great use cases and they will use this new functionality in their deployments. How about you?

All of us at Jabber, Inc. are thrilled by the U.S. Marine Corps’ selection of Jabber XCP for instant messaging, group chat and presence within the broader context of communications and collaboration. See the press release for more details of this landmark announcement.

It is an honor to provide software and services in support of the mission of one of the world’s most renowned and agile military organizations. While best known for its prowess in battle, the USMC is also a leader in the use of technology. I have no doubt that the extensibility, scalability and interoperability of the Jabber XCP platform will facilitate its use in a broad range of innovative applications within the Corps.

After I wrapped-up my Fall VON panel discussion with Avaya, BT, and HP I switched gears to do an interview with VON TV. The five minute video shares some of my thoughts on the value of presence, why protocols don’t matter, and how Jabber simplifies adding presence to applications and services. Check out my early morning mug in Jabber’s “TV” debut.

Download

Walled gardens have been a characteristic of presence and real-time messaging since the beginning, but the time has come for these walls to come down. Presence enjoys the benefits of network effects - the more presence nodes, the more valuable presence becomes.

How can vendors speak of interoperability yet continue to force their customers into walled presence gardens? Can you imagine unified communications systems where the telephony and email services only work within the walled garden? Federated presence, based on open standards, allows users of unified communications systems to view the presence of all of those with whom they need to communicate and to publish their presence to others. The value of presence in unified communications is greatly diminished if it is restricted to a subset of those people - those who happen to be using the same UC platform.

Mike Gotta asks some excellent questions in his report from the Microsoft Unified Communications launch:

The link to presence and identity is a really important point - and to extend that into the area of social computing is another direction to consider re: social presence not just presence as it pertains to a network, device or application (refer to my earlier post “Social Presence: We Need To Push The Reset Button“.

That said - it raises some questions:

• Why does Microsoft still not federate with Google via XMPP?
• Why does Microsoft not openly state its direction on some of the IETF-related presence standards?
• Should Microsoft take its PSOM protocol (used in its web conferencing components) and treat it as an open standard (similar to XMPP)?
• Will Microsoft openly expose its granular rich presence information in a bi-directional manner to other vendors (Microsoft’s assumption is that OCS is the master presence platform but many companies will have more than one presence aggregation point)?

To paraphrase Ronald Reagan’s challenge to Mikhail Gorbachev at the Brandenburg Gate: Open this gate! Unified communications providers, tear down this wall!

The Defense Information Systems Agency (DISA) recently announced that Jabber XCP has been selected to provide instant messaging, low-bandwidth text chat, and persistent multi-user chat for personnel across the U.S. Department of Defense. Jabber XCP will be provided as part of the contract for Net-Centric Enterprise Services (NCES) awarded to Carahsoft Technology Corp., working in partnership with Adobe Systems, Inc. Read the Jabber, Inc. press release for more details.