When 2.0: Bring on calendar interoperability

When 2.0: Bring on calendar interoperability

Summary: The When 2.0 workshop, led by Esther Dyson, kicked off this morning on the campus of Stanford University.

TOPICS: Microsoft

The When 2.0 workshop, led by Esther Dyson, kicked off this morning on the campus of Stanford University. It's a small smallish group, less than a hundred 165 people, many with calendar-based products and an interest in time as a underpowered data type in applications. As is generally the case with software, calendars are tethered to specific platforms, which makes it difficult to ensure interoperability.

During a panel discussion, the participants (see below) pointed to the need for standards to the resolve the complexity and clunkiness of sharing and co-editing calendar information.  "Each [calendar] has its own APIs and code bases, but we have to figure out how to share," said Microsoft CTO Ray Ozzie.


From left: Esther Dyson, Mitchell Kapor, Open Source Application Foundation; Yori Nelken, TimeBridge; Ray Ozzie, Microsoft; Raymie Stata, Yahoo

During his first few weeks at Microsoft Ozzie said he met with various groups at Microsoft with calendaring/time-based functions and came up with the notion that vcards for contacts and iCal for individual events or meetings should be packaged in RSS feeds and then published as categories of entries." The next step, he said, is figuring out how to swap and co-edit, which is where is Simple Sharing Extensions (SSE) fits in, cross linking feeds, editing and swaping data bidirectionally. 

"Standards will free up developers from reinventing the wheel," said Mitchell Kapor, a founder of the non-profit Open Source Applications Foundation (OSAF) and Ozzie's former partner at Lotus Development (Ozzie led the team that developed Lotus Notes). "iCal is fine for data presentation of an event, but when attempting to coordinate a collection of events among multiple computers, there are SSE and CalDAV, a protocol for allowing calendar access via WebDAV, to the extent we have agreement and compliant systems."

The idea is that email/calendar stacks (such as Microsoft's Exchange server, MAPI protocol, Outlook interface or OSAF's Cosmo server, CalDAV protocol and Chandler interface) could use SSE for exchanging and synching calendar information between repositories (servers) bidirectionally.

After the panel Ozzie, Kapor and Lisa Dusseault, who published the CalDAV spec in 2003, were sitting around a table outside in the nippy Northern California air, presumably discussing standards issues and the combination of CalDAV and SSE. I asked Ozzie after the conversation finished for a summary. He said the talks were preliminary and that there was "nothing mutually exclusive in the things we were talking about. It's in all of our best interests to get calendar interoperability," he said. 

It doesn't appear that the technical hurdles to calendar sharing and interoperability are overwhelming, but clearly the politics and desire from some parties to create their own 'de facto' standards is holding back progress...

Topic: Microsoft

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Unwarranted generalization about software

    Dan, there are plenty of examples of existing software interoperability that your generalization ignores. More thoughts here:


    Scott Mace
  • Calendaring is harder than it is given credit for

    I was VP of Engineering for a while at Meeting Maker, and experienced the hell of offering a calendaring product for a while. Calendaring has several subtle, and difficult to address areas:
    - Repeating meetings. this one always trips up the uninitiated. Accurately representing that you want to meet ever third thursday, except for Thanksgiving and except when blah-blah happens, except when blah-blah is in March, ... is unexpectedly hard. There are two issues: simple data representation (in an interoperable way), and even harder: keeping the UI easy for humans to use.
    - Free/busy time. When you're trying to schedule within an administrative domain, most products try to show the free/busy time of attendees. However, the hard part becomes to figure out where this is kept, how the info is kept current, what to do about 'tentative' (proposed, but not accepted) meetings, and how to scale all of the above, and how to do it in an interoperable way.
    - What information to share across administrative domains. I wanted like mad to get inter-organizational scheduling implemented. But there are very thorny issues, especially when it comes to free/busy time. Does Ray Ozzie want me knowing when he is free/busy? I think not - he could be involved in a secret merger deal with Sun, and I could use his free/busy time to ferret out that information. So, what *do* you allow? And how do you allow it?
    - Updates. Meeting events frequently change. Easy to handle with versioning -- yes? What do you version? Each data element? The whole meeting? And given this, what information do you share when you're going across administrative domains?

    And on and on. This is underappreciated.

    Ray, do iCal, don't make this be an RSS thing. There is a single data representation and there are are THREE meeting scheduling protocol choices in iCal, including a calendar-specific one, one based on email, and one based on WebDAV. And these have YEARS of work into them, going back to 1995. Interoperability is *already* hard enough - don't make up something else that has to go through the same growing pains. PLEASE.