iCalendar, CalDAV...then what? Part 2

After I received Alex Pline's email (posted here yesterday) I wrote to Lisa Dusseault, co-creator of CalDAV, and asked her for her thoughts. Here is her reply:

"Hi Scott,

"Alex is not wrong! iCalendar has interoperability issues and it's outmoded. However, those two issues aren't related. An XML-ized version of iCalendar risks having the same interoperability issues unless it's better specified. And even if it is, introducing xCal creates interoperability issues with the big deployed base of iCalendar users. Personally, I'm pretty pessimistic about changes like this being positive unless we have participation by Microsoft. However, if people want to push it forward, they can.

"Standards are made by the people who show up and do work. I hope Alex joins the CALSIFY mailing list or a similar list. He would be most welcome to endorse xCal and that might be part of moving xCal forward. The IETF is always extremely short of the type of contributors who manage issues lists and keep discussions on track."

Today while I was meeting with some other developers, another shortcoming of today's calendar-sharing technology became clear to me. Today, calendar-sharing usually involves email as a transport mechanism. For sending invitations, and RSVPs, these systems usually rely upon the store-and-forward protocol SMTP that underlies email.

Here's why that's a problem. I don't really care if my email takes a minute or two (or even longer) to arrive at its destination. But when I confirm that I've just accepted an invitation to enter a meeting, and if that meeting begins now or in a few minutes, I want that acceptance to appear everywhere it needs to right away, not in a few minutes.

This suggests to me that calendar sharing needs a more real-time protocol underneath it than SMTP. Maybe it needs to be based on something more akin to XMPP, the protocol underneath instant messaging.

Now it may be that iCalendar and CalDAV have all this thought through. Or, maybe not. I'm not an engineer. But put it together with Alex and Lisa's thoughts above, and you can see some of the places where calendar-sharing standards work needs to go next.

As for participation by Microsoft, there is at last some movement on that front. Check out Cameron Stillion's newly-posted comment on a post I made back on March 8. It speaks of Microsoft's "increased involvement" in CalConnect. I suspect I'll see more evidence of that at CalConnect XIII Oct. 6-10 in Santa Clara, California.

Got your own ideas of how to proceed? Send me your comments and emails.

iCalendar, CalDAV...then what? Part 1

I received an email last week that I will reproduce here in its entirety, then comment on in a subsequent post:

"Hi Scott-

"I've been a follower of your blog for a long time. I'm a technical lead for a software development team at NASA Headquarters in Washington DC and what I don't get is why do we, as a calendar community, continue to push improvements to iCal (such as cal dev), when the REAL problem is iCal (RFC 2445) itself? To me it seems like we are trying to improve in very small ways what amounts to a very, very outdated standard. I believe iCal should just be tossed and a much more contemporary calendar standard created based on some calendar-related XML vocabulary, perhaps specifically RDF so that calendar data would play nicely with the Semantic Web.

"We have developed a custom web based calendar application (now in its 4th year) that allows users to subscribe to events using iCal and SMTP as the transport mechanism. NASA has moved to a centralized exchange infrastructure which has helped, but still, creating iCal that plays nicely with both Entourage and Outlook clients is extremely difficult. Each client handles iCal a little differently (especially with respect to All Day Events) and who knows what JuJu Exchange does during the client1-server-cleint2 syncing process. Initially, we were hoping that xCal, an xml-ized version of iCal circa 2000 or so, was going to catch on, but evidently it died due to lack of agreement on the last 10% (recurrence etc).

"Anyway, I wonder why no one ever talks about the need for sweeping reform in this area, given that xml-based syndication has been so successful in the RSS related areas, despite it's checkered "standards" development history.

"Just some food for thought.

"BTW, feel free to use any of this for your blog. I was going to post it as a comment, but it's not really related to any particular post..."

Alex Pline
Exploration Systems Mission Directorate
NASA Headquarters
Washington, DC

Pressure's on Microsoft to support CalDAV

One reason I'm so enthusiastic about the Oracle CalDAV support is that I think it puts much greater pressure on Microsoft to support CalDAV in Microsoft Exchange. Last year, Exchange customer Boeing was reported to have implemented a CalDAV plug-in for Exchange, but only for the free/busy component. Of course, this year Google added CalDAV support for Google Calendar. But Oracle's Beehive competes directly with Microsoft Exchange, so I would say this latest development significantly turns up the heat on Microsoft to get on board the CalDAV express.

Oracle helps drain the swamp

If you're part of an organization that happens to be a big customer of Oracle's, your calendar swamp-draining ship has come in. Oracle Beehive, a suite of group collaboration tools, includes a calendar server that fully supports CalDAV, which means it seamlessly works as a server for a growing variety of clients, including my fave, Sunbird. Of course there's also support for the ubiquitous Microsoft Outlook. If you're at Oracle OpenWorld this week in San Francisco, check out the Beehive demo for other cool features, such as integration with instant messaging that notifies those trying to reach you that you're in a meeting because it says so on your calendar. (They can still IM you anyway, of course.) At any rate, although it's a pricey solution, Oracle earns +2 SwampDrain points for potentially bringing much of big business and big government into a right proper calendar-sharing frame of mind, and for doing it without creating or requiring its own calendar client software, which keeps things simpler.

ifreebusy.com to close

Yesterday I received an email from Neil Jensen, creator of ifreebusy.com. He is closing down the service on October 15 because "it has never really evolved from its early state," Neil wrote. He recommends Tungle, Calgoo or iCalx as alternatives. Neil deserves credit for creating ifreebusy.com at just the right time to move this idea beyond talk as well as beyond proof of concept.

TimeBridge for Mac in wider testing

Timebridge is now testing a connector for Macs running iCal. I wouldn't go so far as to claim, as Timebridge does, that it's the "first scheduling application to integrate with Apple iCal," as Spanning Sync, Calgoo, and Google Calendar's own CalDAV support predate Timebridge for iCal. If someone can explain to me what's so special about Timebridge's Apple iCal "integration," I'd love to know.