From the shores of the Muddy Branch

Introduction talking about past work RFC 2445, RFC 2446, RFC 2447, CAP and new work on CalDAV, GroupDav, RDF calendar work in W3C.

Another spec is out there that uses iCalendar called Call Processing Language (CPL)  – other dependencies may exist also.

So why we are here – many implementations of iCalendar, many proprietary protocols and end users – want an interoperable solutions!!

Vendors are under pressure, Calconnet has been setup to help bring vendors together and many new products coming into the marketplace.

The CALSIFY BOF is now just starting in Minneapolis – not sure if I will be able to blog in real-time – technology is fine – my multitasking ability is not. 

About 35 people here and many more on the jabber session.   The agenda includes an introduction, problem definitions, possible solutions, and the next steps.  With the goal to be a WG charter.

And here we go..

Cyrus Daboo documented many of the issues with the current iCalendar standards (RFC 2445, RFC 2446, and RFC 2447) in preparation of the IETF BOF – Problems in Calendaring and Scheduling  Standards

Jeremy Zawodny

There’s been a lot of speculation about Google Calendar recently. And you know what? I sure as hell hope they do it. There’s been so little innovation in the world of on-line calendars these last few years. Perhaps Google getting into the act would finally change that.

In which Hanan Cohen responded:

The world is buzzing with discussions over calendaring standards. Top hinkers and top companies are involved and nothing big really happens because they are still arguments if RRULES (recurring rules) should be included in iCal-Basic.
…  There’s only one good reason for Google to do it: to do it already! Google can be the leader, deciding on using an incomplete standard and make it the de-facto standard, beacuse they can.

The next chance for trying to get a new standard will be the IETF BOF meeting March 10. – I will be there and blogging about it! 

The big Calendaring news this week is Novell’s announcement of the formation of Hula, a new community project to create an open source collaboration server based on the NetMail product.

Planned features include:

• Appointment Manager. Invite anyone to an event and track RSVPs.
• Calendar Publication. Make it easy to create, manage and publish publicly-available calendars that your friends can subscribe to.
• Shared Calendars. Create team calendars with multiple editors.
• Reminders. Get notifications of upcoming appointments via mail, IM and SMS.
• Calendar URLS. Simple and easy ways of reading calendar data, in multiple formats, via nice-looking URLs.
• CalDav. The emerging standard in calendar clients is to read and write calendar entries on a server using WebDav and the iCalendar format.
• Text Interface.  Access your calendar from any text interface, querying and creating appointments from mail, IM or SMS.
• Calendar Aggregation. View multiple calendars at once.
• Printable Calendar. Render the calendar into pretty PDFs.

Not everyone is excited, Ed Brill of IBM / Lotus was quick on the FUD posting. 

Time will tell.

The Calsify group from calconnect, has requested a BOF slot for the IETF meeting in Minneapolis to jumpstart a new IETF working group charter as stated below thanks to Cyrus Daboo

Calendaring and Scheduling is currently defined in RFCs 2445, 2446 and  2447. These documents have been available for several years now, and a number of implementations exist. However, a number of interoperability problems exist between these implementations, some due to bugs in the specifications, some due to lack of clarity in the specifications and some due to under specification of key behaviors. As a result, interoperable calendaring and scheduling has not been truly achieved.

The purpose of this BOF is to discuss revising RFCs 2445, 2446 and 2447 with the primary goal of achieving interoperability over the range of calendaring and scheduling tasks needed in real world situations. The goal of the BOF is to come up with a clear direction on how those revisions should be done, including the scope of changes. The desired outcome is a set of major charter points and milestones for a proposed IETF calsify working group.

Input to this BOF will be a problem statement internet-draft draft-daboo-calsify-issues-00.txt that pulls together existing document errata, known problems with the specs and results from interoperability tests. In addition, draft-royer-ical-basic-02.txt provides one possible direction for revisions.

Proposed agenda follows:

Agenda

- Introduction (blue sheets, scribe etc) (1 min)
- Agenda Bashing (3 mins)
- Introduction (6 mins)
- Problem statement document (60 mins)
- Possible Solutions (40 mins)
- Next Steps/WG CHarter (10 mins)

Total 120 mins

owTime Zone Registry Draft-00 Dr has been submitted to the IETF for consideration.

This is a submission for the creation of an new IANA Time Zones registration process. This is a registry for iCalendar VTIMEZONE calendar component information. Time zones and their definitions are required in order to schedule and synchronize meetings and software. The condition in which these time zones change are subject to civil authority rulings are are not always determinable by software algorithms.

More on this later..

ICAL-BASIC Draft 01- has been posted to the IETF.  It fixed some problems, typos and deprecates the DTEND parameter in favor of DURATION, based on comments and suggestions received.

ICAL-BASIC Draft 01 can be found at: http://www.ietf.org/internet-drafts/draft-royer-ical-basic-01.txt

Journal specifications were an easy hit – almost no vendor provides interoperable capabilities within the format and weblogs have now become the preferred standard.

Removing To Do’s had a more heated discussions, in the end two themes seem to prevail: first, the issue with the current iCalendar standard is that it tried to do everything and may have short-changed the To Do schema. The message here was not to repeat the same mistake. The second theme was that with extensions, it would be simple to add a new To Do spec – hopefully with a better model.

That’s it on the major changes from RFC 2445 to ICAL-BASIC

Comments appreciated here and on the ietf-calsify mailing list

After recurring rules, time zones cause the most interoperability troubles. The good news is that most of the issues are due to the recurring rules – which have been removed from iCAL-Basic. Removing time zones from ICAL-Basic will allow better approaches to be applied when ICAL-Basic is extended.

ICAL-Basic will supports both local times and single instances specified in Coordinated Universal Time (UTC). The two proposed formats are as follows:

FORM #1: DATE WITH LOCAL TIME

The date with local time form is a date-time value that does not contain the UTC designator. For example, the following represents January 18, 1998, at 11 PM: DTSTART:19980118T230000.

These local date-time values are said to be "floating" and are not bound to any time zone in particular. They are used to represent the same hour, minute, and second value regardless of which time zone is currently being observed.

FORM #2: DATE WITH UTC TIME

The date with UTC time, or absolute time, is identified by a LATIN CAPITAL LETTER Z suffix character (US-ASCII decimal 90), the UTC designator, appended to the time value. For example, the following represents January 19, 1998, at 0700 UTC: DTSTART:19980119T070000Z

This format requires that your calendar application (desktop, web, PDA, cell phone, etc.) will need to know your local time zone and perform the calculations from UTC.