one small voice

stpeter's blog on jabber, technology, history, philosophy, et alia

about

who
what
where
when
why
how
comments

feeds

ATOM

RSS

2005-09-29

IMbox

Some Jabber/XMPP tidbits.

The Jabber/XMPP world continues to move forward. Here's some news I've noted recently on the web:

General Dynamics has implemented a Jabber/XMPP application for the U.S. Department of Homeland Security.
The Gizmo Project has soft-launched its XMPP support.
The Jive Software folks held an informative groupchat with Rod Chavez of the Google Talk project.
The new Meebo Web IM service now supports Jabber/XMPP.
NewsForge has a nice article about the Gajim client for Linux.
Robert Quattlebaum has written a small application that enables your Mac to properly handle xmpp: URIs.
The new Sieve notify Internet-Draft has nice things to say about Jabber notifications.
There have been new software releases from PunJab, Jive Messenger, mcabber, neos, XMPP4R, and Jeti (among others).

Posted on 2005-09-29 at 14:23. File under jabber.

~ link ~

Planting a Seed

Anglospheric blogging.

It seems that Jim Bennett has converted Albion's Seedling into a group blog, so I'll be posting some of my societal musings over there from now on (cross-posting here as appropriate). Check it out!

Posted on 2005-09-29 at 12:13. File under society.

~ link ~

2005-09-28

All Moved

Settling in, catching up.

My scheduled quiescence is over and we're getting settled into our new house in the University Park neighborhood of Denver (plus I'm getting caught up on all the hundreds of emails I received while offline). Expect a return to blogging normalcy here soon...

Posted on 2005-09-28 at 10:03. File under personal.

~ link ~

2005-09-13

Scheduled Queiscence

Going offline for a spell.

After tomorrow's Jabber Council meeting, I'll be offline for about 10 days while Elisa and I complete our previously-mentioned move to the University Park neighborhood of Denver. Blogging forecast: light to nonexistent. :-)

Posted on 2005-09-13 at 12:53. File under personal.

~ link ~

FutureVision Redux

Technology trends in 2010 and beyond.

I've posted a PDF version of the slideware I presented last Friday at the FutureVision 2010 conference. I'm not sure how much the faculty, students, and industry specialists got out of my presentation, but I enjoyed giving it. One of these days I'll turn it into an essay with proper references and such, since the slides are a bit cryptic.

Posted on 2005-09-13 at 12:41. File under technology.

~ link ~

TINS

More on standards convergence.

Last week I opined about XMPP, SIP, and SIMPLE, so I thought I would follow up with a more reasoned post about how XMPP and SIP can interoperate in the realm of Internet telephony (a.k.a. VoIP). As Joe Hildebrand notes in a recent interview/article that's riddled with the usual journalistic inaccuracies (not Joe's fault if my experience with journalists is any guide), once upon a time folks in the Jabber community strongly considered building our own protocol for multimedia session negotiation and management. For example, we could have defined a lightweight stream initiation profile as the way to get to RTP (the real-time transport protocol) for the data transport. The problem is that then we'd have a lack of interoperability with emerging SIP-based VoIP systems like the Gizmo Project (which will soon be adding Jabber/XMPP support for messaging). Yes, I know some people say that SIP is a bloated mess and that IAX is superior to SIP. All that and more may be true. But the folks who've worked on RTP, Session Description Protocol, and Session Initiation Protocol have put a lot of work into getting the semantics right, and I don't see a compelling reason for the Jabber community to re-invent the wheel. Instead, the TINS spec defines "A Transport for Initiating and Negotiating Sessions" which is compatible with SIP. In particular, TINS is an XMPP extension that does two things:

Defines a way to transport Session Description Protocol data over XMPP.
Defines how to map SIP header information to XMPP via the Stanza Headers and Internet Metadata (SHIM) protocol extension.

As a result, native XMPP clients that support TINS can re-use all the semantics of SDP and SIP in order to negotiate and manage multimedia sessions (which usually means finding a way to agree on how to use RTP). They can also interoperate with native SIP clients through TINS gateways running at the boundary between XMPP services and SIP services. The result may not be the most beautiful protocol and architecture ever imagined, but we're not in the business of aesthetics, we're in the business of connecting people.

(Another form of connection is to enable SIP clients to launch XMPP sessions for IM and structured data exchange, but that should be pretty straightforward using the approach outlined years ago by Robert Sparks. Perhaps we need to codify that in a more formal Internet-Draft or JEP -- it would be a damn sight simpler than MSRP!)

Posted on 2005-09-13 at 12:11. File under jabber.

~ link ~

Blogiversary

Four years and counting.

It seems that today is my blogiversary, since the first post to this blog occurred on 2001-09-13 (right after the 9/11 atrocities). I don't know that it's worth celebrating, since the result has been been four years of ceaseless yammering at my little soapbox here (can you say blogorrhea?). We'll let history be the judge, I suppose. :-)

Posted on 2005-09-13 at 11:37. File under personal.

~ link ~

2005-09-08

Intangibles

Violence and civilization.

Toward the end of How the Mind Works, Steven Pinker makes the following observation about the relative levels of violence inside and outside of civilizations:

Why don't we see periodontists or college professors dueling over a parking space? First, they live in a world in which the state has a monopoly on the legitimate use of violence. In places beyond the reach of the state, like urban underworlds or rural frontiers, or in times when the state did not exist, like the foraging bands in which we evolved, a credible threat of violence is one's only protection. Second, the assets periodontists and college professors, such as houses and bank accounts, are hard to steal. "Cultures of honor" spring up when a rapid response to a threat is essential because one's wealth can be carried away by others. They develop among herders, whose animals can be stolen, more often than among crop-growers, whose land stays put. And they develop among people whose wealth is in other liquid forms, like cash or drugs.

Just a note toward some future essay of mine on the rise of civilizations...

Posted on 2005-09-08 at 21:29. File under society.

~ link ~

2005-09-07

FutureVision

Technology trends in 2010 and beyond.

It seems I forgot to mention that I'm giving an invited talk this Friday at the FutureVision 2010 conference being held on the campus of Colorado State University. Check out the program for details. The talk is not about Jabber or any specific technology, more about technology trends caused by ubiquitous computing and always-on connectivity. But you can be sure that presence, identity, real-time communications, security, and intellectual property will be part of the mix... :-)

Posted on 2005-09-07 at 12:17. File under technology.

~ link ~

2005-09-02

XMPP, SIP, and SIMPLE

The law of standards in action.

It's now clear that both XMPP and SIP are important technologies that will co-exist for a long time. XMPP (see RFC 3920) provides a streaming XML transport that is useful not only in instant messaging but in any application space where it's necessary to move structured data from one point to another (pubsub, SOAP, RPC, Atom, you name it). SIP (see RFC 3261) provides semantics for managing multimedia sessions (or even XMPP sessions) and is the preferred mechanism for negotiating how entities will set up the use of RTP (see RFC 3550) for the multimedia streams themselves.

So how will XMPP, SIP, and RTP work together? (No, it's not just SIP and XMPP.) The developers of Google Talk made their own custom XMPP extension for their voice functionality but say they will be supporting SIP in the future. It's too bad they didn't use TINS, since that would make gatewaying to SIP pretty darn easy. It strikes me that anyone who's serious about XMPP-SIP interop will either use TINS on the XMPP side (with gateways to SIP networks) or develop a dual-headed client that includes both XMPP and SIP support. Either way you slice it, both TINS and SIP enable you to get down to RTP, which is where you really need to be in order to do multimedia.

That's XMPP and SIP. XMPP and SIMPLE is another question. SIP is a rendezvous or negotiation protocol, whereas SIMPLE is a set of extensions that enables applications to send messages and presence information over the channel that's normally used for multimedia negotiations. Work on SIMPLE began in the IETF back in 2001 (after it became clear that the Instant Messaging and Presence Protocol WG would fail in its mission of developing a common protocol) and continues to this day. So far the SIMPLE WG has developed a way to send single messages between SIP users and a way to share presence among SIP users. They don't yet have a settled way to implement basic features like chat sessions rather than single messages (though after several attempts they seem to be settling on MSRP), contact or "buddy" lists (though see the somewhat scary XCAP spec), or groupchat (presumably that will be developed in the XCON WG). There are still many holes in the SIMPLE protocol stack, and companies who've implemented it so far have needed to "embrace and extend" SIMPLE with proprietary extensions in order to offer even a minimally functional IM and presence offering (think LCS). The result is, sadly, a lack of interoperability.

Some claim that SIMPLE is the de-facto standard for IM, but the claim is dubious and we're hearing it less and less these days. SIMPLE is years away from being full-featured or stable. Organizations that want to offer IM and presence solutions today can't wait years for SIMPLE to settle, they need a proven technology that they can deploy today -- as witness the Wall Street investment banks, major portions of the U.S. government, leading-edge companies who want to generate competitive advantage, and a number of large service providers (most recently Google and Wanadoo, but also BellSouth, Portugal Telecom, Sapo, etc.). And organizations that can wait years for SIMPLE to be fully baked are not all that serious about IM and presence -- they're more interested in protocol posturing than in getting the job done or meeting the needs of their customers.

One thing that has always surprised me is IBM's stance in the IM and presence space. You'd think that with their commitment to Linux, open source, and open standards, they would have embraced Jabber/XMPP technologies years ago. Instead, they continue to sell Lotus Sametime, which is based on a completely proprietary technology and protocol. Granted, they are rumored to offer a SIMPLE gateway to their customers, but that's a gateway, not the core technology. And if we can judge by a recent blog entry from IBM Distinguished Engineer Carol Jones, IBM still does not understand Jabber/XMPP technologies. Carol seems to be of the "SIP is the one ring to bind them all" philosophy. She states, inexplicably, that "SIP has backing from most large companies in the IM space" but we certainly haven't seen that in deployments, AOL and Yahoo continue to use their own closed protocols, and only Microsoft (with the aforementioned LCS) has made a half-hearted attempt to use SIMPLE -- with less-than-stellar results in their few major deployment attempts and no ability to federate domains (standard with Jabber/XMPP since 1999!). She thinks that XMPP is dead because it's no longer active in the IETF. Granted the SIMPLE WG continues to soldier on and probably will for years to come, but XMPP is quiet in the IETF because the XMPP WG completed its mission. Are TCP and HTTP dead because there are no active working groups for those technologies? XMPP most certainly is a part of the IETF, but the Jabber/XMPP community develops extensions to XMPP within the standards process of the Jabber Software Foundation rather than burdening the IETF with massive numbers of Internet-Drafts (I sometimes think that the SIP community, with four working groups and endless activity, is effectively a distributed denial of service attack on the Internet Standards Process). As to the relationship between continuing XMPP development and the IETF, think of it this way: W3C is to HTTP as the JSF is to XMPP (except the JSF uses an open standards process, unlike the W3C's closed consortium). In implementation land, Jabber/XMPP servers have been proven to scale to hundreds of thousands of concurrent users, which we have not seen with SIMPLE servers to date. Jabber/XMPP technologies have a well-understood client-server architecture that is easy to deploy, whereas the fundamentally peer-to-peer nature of SIP/SIMPLE services sounds appealing but ends up being a logistical and compliance nightmare for the system administrators who actually have to manage IM and presence services day to day. And the list goes on.

Some years ago, John Sowa formulated The Law of Standards, which is consistent with years of experience among the Internet community. The law states that simple, deployable technologies tend to emerge within a small, dedicated team of practical-minded developers (think C, HTTP/HTML, SMTP, Linux), whereas unwieldy, undeployable technologies tend to emerge from a bureaucratic process within large committees, companies, or consortia (think Ada, SGML, X.400, OS/2). XMPP is a simple technology (originally developed within the Jabber open-source community and formalized within the IETF) that has been and continues to be adopted by serious organizations who want to leverage the power of IM and presence in the real world. SIMPLE is perhaps one of the most tragically misnamed technologies ever created -- and while some large organizations pay lip-service to it, there's a conspicuous lack of deployment. I realize that some organizations may deploy SIMPLE systems (heck, there are probably still some X.400 email services running out there somewhere) and I've even taken the lead in specifying how SIMPLE-to-XMPP gateways can work, but I also think that simple, deployable technologies always win out in the long run. And in the IM and presence space that means XMPP.

Posted on 2005-09-02 at 14:47. File under jabber.

~ link ~

2005-09-01

CAcert HOWTO

Getting started with the web of trust.

The CAcert website is confusing so here's a mini-HOWTO on getting started with the web of trust.

Go to www.cacert.org and click the "Join" link at the top right.
Fill out the form. It is very picky about passwords (you're supposed to enter something "strong" so include a combination of letters, numbers, and special characters). Also you need to make up five lost passphrase questions -- I suggest things like your first pet and/or teacher, favorite (or least favorite) song, author, novel, vacation spot, etc.
Once you're finished, you'll receive an email from CAcert. Click the link contained therein to complete the registration.
Install CAcert's root certificate (note: if you want to use CAcert with MS Outlook, make sure you install the root certificate using IE!).
Go back to www.cacert.org and log in. You can now generate a certificate (click "Client Certificates" in the website navigation) and sign your email messages (more on that in another blog entry), but the certificate won't include your name. If you want to include your name (it's a good thing!), you need to get points in the web of trust by meeting people called "assurers". An "assurer" is someone who verifies your identity by meeting you in person, inspecting your government-issued photo IDs (GIPIDs), and signing your web of trust form. You find assurers in your area by clicking the "Find an Assurer" link under "CAcert Web of Trust". So we begin round two...
Click "CAcert Web of Trust" in the right navigation and then click "A4 - WoT Form" or "US - WoT Form" depending on what paper size you prefer, then print out the form.
Take the form, along with two GIPIDs, to one of the CAcert assurers. (In some countries, you can show one GIPID and one non-photo ID like a birth certificate, but in general it is best to bring something like a driver's license and passport.)
If you can't find any assurers in your area (it happens!), you need to be verified through the "Trusted Third Party" route by printing the TTP Form, making copies of your GIPIDs, visting two notaries, lawyers, CPAs, or other trusted individuals, having them witness and sign your documents, then sending the TTP Form and GIPID copies in the physical mail to the CAcert offices in Australia. This takes longer but enables you to start with 150 points in the web of trust (it's what I did to get started).
Once you have at least 50 points in the web of trust, you can generate a certificate that enables you to include your real name in there, thus enabling people to know that the email really is from you. The 50-point level also enables you to get assured server certificates so that you can offer SSL encryption at your website or Jabber server. Once you have 100 points in the web of trust, you can sign code that you write, and you can also become an assurer to help spread the web of trust. (More about the different levels here.)

There are more details to explain about how exactly to sign your email (depends on what email client you use, but I found it was quite easy in Thunderbird) and how the web of trust points system works (some assurers can grant you only 10 points, some can grant up to 35), but I'll leave those for another blog entry.

Oh, and if you get stuck, don't depend on the CAcert website, because it's kind of confusing. The wiki is much more useful right now...

Posted on 2005-09-01 at 10:01. File under technology.

~ link ~

SSO Redux

Wired on identity again.

Wired magazine certainly likes to write about the prospect of single sign-on for the Internet. Last month it was a story about the GoingOn Network, today's it's a story about a company called Just1Key. Perhaps one of these days they'll report on open technologies for SSO rather than centralized, closed-source solutions. Passel, anyone?

Posted on 2005-09-01 at 09:17. File under identity.

~ link ~

Assurances #20 and #21

CAcerting along.

Yesterday I initiated two more Jabber Inc. folks into the ways of CAcert: Danny Price and Chris Williams. The company is a real hotbed of CAcert activity these days!

Posted on 2005-09-01 at 09:03. File under technology.

~ link ~

Moving UP

Changing places.

Elisa and I will soon be moving to UP -- no, not to Michigan's Upper Peninsula, but to Denver's University Park neighborhood. Expect me to disappear for a week or so later this month as we move house about 2 miles south from our current location.

Posted on 2005-09-01 at 08:59. File under personal.

~ link ~

identity...