From the shores of the Muddy Branch

RFC 4324 Calendar Access Protocol (CAP) was officially published today by the IETF. CAP will provides a universal methodology for implementing real-time calendaring.

CAP permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an iCAL-based Calendar Store (CS) and manage calendar information.  In particular, the document specifies how to query, create, modify, and delete iCalendar components (e.g., events, to-dos, or daily journal entries).  It further specifies how to search for available busy time information.

I am at the Syndicate Conference in San Francisco doing the first demonstrations of IntelliCal’s  calendaring products. Reactions have been great to date and we were able to prove our interoperability with Tantek Çelik hCalendar to iCalendar converter. Tantek posted the Syndicate Conference sessions and tracks in hCalendar and we subscribed to them in our forthcoming product.

Good timing for the announcement later this afternoon on Structured Blogging in which IntelliCal is a participant. 

We will be launching soon……

Esther Dyson’s When 2.0 conference was yesterday and some of the sessions covered how events go beyond calendaring with respect to time management and revenue management.  It would have been interesting to have someone from the Business Process Management perspective, like ourselves or Meeting Maker now PeopleCube.

The best quote I read was from ZDNet’s Dan Farber

"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…"

For a full account of the conference Oren Sreebny’s Weblog is the place to go.

[When 2.0] Esther’s intro

[When 2.0] Mitch Kaopr, Yori, Ray Ozzie, Raymie Stata

[When 2.0] Pavel Curtis (Microsoft)

[When 2.0] Startup panel

[When 2.0] Afternoon Panel – Time and Functionality

[When 2.0] Time and Detection Panel

[When 2.0] Will Wright (Maxis/Electronic Arts, and the creator of Sim City)

p.s. No gCal announcement.

Tomorrow is Esther Dyson’s When 2.0 conference.  We will be at Syndicate next week and had to miss this one.  If true, When 2.0 may be the conference to attend – the big rumor is  Google will unveil its long-rumored "gCal" calendar app.

Trying to stay ahead of the news Trumba pre-announced it New Online Service to Publish and Syndicate Events to Any Calendar.  I will be interested to see the details. Trumba also announced a partnership with Knight Ridder for Community Calendar Publishing.  From the example in the press release the Community Calendar and the New Online Service may be the same Two announcements once for service – one for partner.

Ray Ozzie has proposed Simple Sharing Extensions or SSE to solve a long term problem of sharing information between two or multiple entities. Per the FAQ:

SSE defines new XML elements that add replication information to items in an RSS feed. These new elements enable SSE applications to implement bidirectional RSS. In other words, two endpoints can mutually publish and subscribe to each other’s RSS feed. When changes are made in one endpoint, they are propagated to the other and vice versa.

Furthermore,

SSE is ideal for replicating data that can be published in an RSS feed. That includes lists of items such as calendar appointments, contacts, favorites, and news items. In addition, SSE is ideal for bidirectional, asynchronous replication, particularly for scenarios where multiple people can edit or create entries.

Excellent Idea!

Dave Winer who participated with some of the refinement is happy to see that Microsoft and others are now “empower(ing) each others’ creativity." As it is “simple” and “available for everyone to use.”

Russell Bettie pointed out, SSE is for syncing only and what is missing is how to represent the data within an RSS Feed.

The SSE just manages the syncing itself – there’s no place for the data to sit besides what’s in RSS already. Where does this other stuff fit? In plain text in the description field? No way. Either he’s talking about using this system with a bunch of different namespaces generated from various applications, or the next step must be an arbitrary field-data namespace for this sort of info

For calendaring, the answer is simple; embed iCalendar in XML Format (xCal-Basic) as its own RSS namespace. xCal is ideal for the basis for RSS Calendar (something IntelliCal has been working on….) while enabling translations back to the many existing calendar clients which support the iCalendar standard.

First step is to draft a spec to embed xCal into RSS (most likely under the Creative Commons License)

Let us know if you want to help out on the spec!

Zimbra Inc. on Tuesday launched what it claims is the first open-source group scheduling calendar—and with it comes the first publicly available release of its Network Edition, targeted at enterprises.

Supporting iCalendar, RSS and ATOM.  While scheduled for a future release -  their calendar images are great!  We look forward to using / working with their products.

A last call was made on iCalendar in XML Format (xCal-Basic).  The draft can be found at:  http://www.ietf.org/internet-drafts/draft-royer-calsch-xcal-03.txt

xCal is a representation of iCalendar objects in XML. xCal is not an alternative or next generation of iCalendar.  (Emphasis mine)

Response has varied from one side: Why do we need another format as iCalendar is working? to the other: If you are using XML why not fully use all the XML capabilities and shed some of the past iCalendar issues?  Both are good questions.

With respect to the why another format question. We see Service Oriented Architectures (SOA) as the future of business, as do many other companies including the top calendaring companies, IBM (Lotus Notes), Microsoft (Microsoft Exchange and Outlook), Novell (GroupWise), plus many others. SOA is primarily enabled by standard-based protocols, such as, the web services stack of XML, SOAP, UDDI, and WSDL.  iCalendar ICS files do not play well within this space.  For calendaring and scheduling to be part of the future then iCalendar needs to be represented in XML. xCal is this representation.  The iCalendar components, properties, and parameters as defined xCal for use in XML.

With respect to question 2, Why not fully use all the XML capabilities?  iCalendar is the current prevailing calendaring standard today and to the most part is interoperable between the major calendar vendors. Therefore, trying to propose a new standard that does not take into account the millions of existing users and majority of software in existence would simply not be acceptable.  xCal uses an exact 1 to 1 mapping between iCalendar and the XML objects and does not introduce any semantics not already defined by the iCalendar standards.

xCal format was selected to ease translation back to the iCalendar format using XSLT to ensure compatibility with existing calendar clients.

To further ensure compatibility, IntelliCal, has released, xCal2iCal, to open source. xCal2iCal is an application using XSLT, which transforms XML xml:lang attributes into iCalendar LANGUAGE parameters.  xCal2iCal can be found at: http://sourceforge.net/projects/icalendar/