Calendar Data Structure Icalendar - RFC 5545 This Is the Mother Speciﬁcation - Where It All Starts

Calendaring The standards and protocols

A brief history It started back in 1995 with the Versit consortium, with members Apple, AT&T, IBM and Siemens, producing a paper deﬁning a vCalendar object. Note the “V” there - it will turn up a lot later on.

In 1997 work started on the Calendar Access Protocol (CAP)

For whatever reasons, this was presumably not considered good enough and in 1998 RFC 2445 appeared. This deﬁned a number of objects starting with “V”, VCALENDAR, VEVENT, VTODO, VJOURNAL, VTIMEZONE and many properties and many rules for their use.

In addition, RFC 2446 deﬁned how events and tasks can be used to schedule meetings and tasks and RFC 2447 deﬁned how that information may be transported over email.

As an aside, that was 1998 and iMip still causes problems.

These standards were supported by many vendors - all slightly differently. Transport of calendaring information was very hit or miss and there was no calendar speciﬁc protocol other than iMip. Not very much changed for a number of years.

Around 2000 work on CAP and the standards essentially stopped. CAP fell prey to disagreements and its own complexity. Vendors started adding proprietary enhancements to the standard which worsened the interoperability problems.

In 2004 a number of vendors felt something needed to be done and CalConnect was incorporated to promote interoperable calendaring and scheduling.

Around the same time a new protocol had appeared, CalDAV and CalConnect took upon itself the mission of correcting the existing standards and promoting the new protocol.

CalConnect was not and is not a standards body but works with standards organizations such as the IETF and OASIS.

In 2009, RFC 5545 came out and obsoleted RFC 2445. Many inconsistencies in the original speciﬁcation were removed and a number of properties were deprecated. Oddly enough, despite the time that had passed, nothing was added to the standard.

RFC 2446 (iTip) was obsoleted by RFC 5546 RFC 2447 (iMip) was obsoleted by RFC 6047 CalConnect continues to promote calendaring and its technical committees have led to a number of new standards or draft standards. From 1998 to 2004 little changed in calendaring. Then…

2007: RFC 4791 - CalDAV Calendaring Extensions to WebDAV (CalDAV) 2009: RFC 6321 - Xcal - the XML representation of iCalendar 2012: RFC 6638 - Scheduling Extensions to CalDAV 2012: OASIS CalWS-SOAP SOAP Web Services Protocol for Calendaring 2013: RFC 6868 - iCalendar parameter encoding 2014: RFC 7265 - jCal: The JSON Format for iCalendar 2015: RFC 7529 - RSCALE - Calendar scale fro non-gregorian calendar systems

Many of these involved new iCalendar properties.

In process • 2015? Tzdist - timezone distribution protocol • New Properties for iCalendar • CalDAV Timezones by Reference - STATUS: accepted by WG • Calendar availability • Calendar relationships • Task extensions • Event publishing extensions • WebDAV sharing specs notiﬁcations, resource-sharing, calendar-sharing • VPOLL • iSchedule Calendar Data Structure iCalendar - RFC 5545 This is the mother speciﬁcation - where it all starts.

Components This speciﬁcation deﬁnes the following components:

• VCALENDAR - to contain one or more of the rest • VTIMEZONE - a representation of a timezone speciﬁcation • VEVENT - events, meetings • VTODO - tasks • VJOURNAL - journal items • VFREEBUSY - to communicate freebusy

Each of these in iCalendar is represented by a “name:BEGIN”, followed by properties and components and terminated by “name:END”, e.g.

VCALENDAR:BEGIN VERSION:1.0 VEVENT:BEGIN DTSTART:… … VEVENT:END VCALENDAR:END

Properties The components all contain properties. A property consists of a name, zero or more parameters and a value. For example

DTSTART;TZID=America/New_York:20150619T150000

The name is DTSTART, the parameter is “TZID=America/New_York” and the value is “20150619T150000”. The speciﬁcation deﬁnes this as a start time with a local time of 15:00 on June 19th 2015 in timezone America/New_York.

VEVENT - events and meetings Events can define: • A point in time • A period of time • 1 or more days They can recur according to rules or with specified recurrence dates. They can define locations, their status (confirmed, tentative, canceled).

If they have organizers and attendees that deﬁne meetings and may be sent to the attendees, either via iMip or by one of the available protocols.

VTODO - tasks Look much like events but rather than an end they have a due date. Not well suited for many purposes - work going on to improve that. Work OK for reminders.

VJOURNAL Not much used, though used by Exchange/Outlook for notes.

VTIMEZONE Used to send a speciﬁcation for the timezone along with the events/tasks. Most of these are only useful for the event they are carried with. Most services and clients ignore these and use the standard set they obtained from other sources. Timezones Timezone information is usually stored as part of the operating system and updated when the system is updated. This results in signiﬁcant delays in delivering timezones which can change at a moments notice.

As we become more connected and schedule more meetings across timezones it becomes more important to update this information in a timely manner.

To this end CalConnect has been working on a timezone distribution protocol to deliver timezone information as data.

Timezones are stored in JVMs, database systems as well as the OS. Two main sources of timezone data are currently Microsoft and Olson. Recurrences Recurrence rules turn up in events, tasks and availability. A recurrence rule lays out a sequence of dates based on the start date of the component.

Recurrences are closely coupled to timezones. Daily recurrences may occur every 24 hours with occasional 23 or 25 hour days.

A recurring event has an RRULE (or RDATES) and possibly some associated overrides. Overrides are what we get when an individual instance is changed in some way. This becomes a particular problem when we have a long running recurring event, e.g. a weekly meeting, in which every instance is changed - e.g. to set the agenda.

An RDATE is used to add an instance by explicitly specifying he recurrence id in the master event. An EXDATE does the reverse - effectively deleting the speciﬁed instance.

Instances are identiﬁed by a recurrence id which has the same format as the start date. That is - it may have a timezone id.

Certain features of recurring events are not necessarily supported. Some clients don’t support RDATES. Calendar Protocols

CalDAV Based on WebDAV this is an open standard and that used by Apples iCloud service and implemented in their clients. Many other service providers have a CalDAV service even while they promote their own proprietary service. CalDAV is the only functional open calendaring protocol.

For all its failings it has completely changed the face of calendaring bringing it much closer to the kind of experience we get with email.

CalWs-SOAP Currently this supports basic calendar access. Deﬁned for use in Ws-Calendar and the smartgrid. Supported by the Bedework calendar system.

Other existing protocols All other extant protocols are proprietary. Perhaps the most important are those provided by Microsoft, EWS and ActiveSynch. Google has a large share with their own API though they do also support CalDAV

Futures Calconnect is working on new protocols - possibly a RESTful api. Scheduling The traditional way The ‘traditional’ approach as deﬁned in RFC 5446 requires the event (or task) to have an ORGANIZER property and 1 or more ATTENDEE properties.

The organizer creates the meeting and adds the attendees. It was assumed that the organizer would check the attendees freebusy and pick a meeting time that would work for all attendees.

The meeting request is sent to the attendees who may accept, decline or counter.

If everybody accepts you’re ﬁne. In certain working environments this approach can work. In many, perhaps most it does not work.

Counter allows an attendee to offer an alternative time. Note there may be many attendees any of whom could counter. This is why counter is not implemented in CalDAV.

This was the only scheduling solution in 2006 when we accepted the Freebusy challenge set by Boeing. The Dreamliner was the ﬁrst aircraft built by a number of outside contractors and then assembled by Boeing. As a result they had to schedule numerous meeting with those contractors and determined it cost about 21 hours to put together a meeting.

They believed that having access to the freebusy of all the parties would help so we designed and built a proof-of-concept application called the freebusy aggregator.

Mariachi bands.

Freebusy doesn’t work For most at least. Why? • Don’t want you to see my freebusy - it reveals private information - like how busy I am • I don’t maintain my calendar - freebusy is not accurate • I’m so important my calendar is full for 3 years - I might open up a slot for your meeting • It’s an aggregation of things - some which you have no access to. • Maybe I just don’t want to meet you on Thursdays

In the case of Boeing it was mostly the ﬁrst - contractors aren’t going to tell them how busy they are - they work on the Airbus as well. They’re not allowed to tell Boeing.

Scheduling the new way What’s the answer? Our hope is that a combination of upcoming standards will make scheduling work. In fact many non-standard based services already exist to provide a way to agree upon a time for a meeting. In the past the organizer would generally give up on the standards approach and use the phone or email. Having agreed on a time they create the meeting request. Web based voting services we all use now provide an online version of that.

Calconnect is working to produce a standard that allows these services to communicate using a well-deﬁned component - VPOLL.

VPOLL This component contains a number of choices and identiﬁes the VOTERs. It allows for different POLL-MODEs. Modes suggested so far include: • BASIC - voters rank the choices. Most favored wins - already implemented • Task-assignment - assign one or more tasks to one or more actors. • Signup - a social mode - who’s bringing what to the party?

This component standardizes the interactions we see in web based services and builds on the features and services available in CalDAV.

Other uses for VPOLL are in the SmartGrid - it provides a way of transporting requests for power and responses to those requests.

VAVAILABILITY This was defined for a number of reasons - it started life as an answer to a need to define a faculty members office hours, those in which they are available for meetings with students.

A VAVAILABILITY component deﬁnes a period, perhaps inﬁnite in which you are busy. Contained AVAILABLE components carve out available slots in that period. They may recur so that you can express such things as: I am available every Wednesday from 9-5

It also has its uses in the SmartGrid - deﬁning periods of time in which produces can provide certain amounts of power or deﬁning the needs of a consumer.

Carried in VPOLL these allow consumers and providers to match up capabilities and come to an agreement.

A VAVAILABILITY component is also considered a valid reply from a voter in basic poll voting. When provided with choices it allows the voter to effectively say - “I don’t know - here’s when I’m available” Other work

Rscale This speciﬁcation allows calendar data to represent recurring events in non-gregorian calendar systems.

It is relatively easy to represent any given date in any other calendar system. However, recurring events are a different matter. Recurrences are important in all cultures because they represent birthdays, religious and civic holidays and so on.

Rscale allows us to specify what scale is used to calculate the recurrences. Work in progress

Updating Tasks The VTODO component was supposed to represent a task. In fact there was so much missing that it was only suited for reminders. Some recent work has tried to align tasks (and calendaring in general) with the needs of business processes and project management.

Major additions have been • Time based relationships - those found in standard project management • Better status reporting - align with business processes • Estimated completion times • Actual times • Better categorization to link related tasks

The intent is to provide a standard mechanism for expressing time based tasks.

Timezone distribution service Timezone data has typically been distributed along with system updates. The timezone distribution service (speciﬁcation now almost an RFC) is designed to allow more rapid distribution by treating it as data.

The approach is to allow multiple timezone servers obtaining data from one or more publishers. Currently the only publisher to be represented is what was formerly the Olson data - now managed by the IETF.

Calendar extensions Addition of properties to allow better description of a downloadable calendar. Addition of properties for conferencing. iSchedule A protocol for transferring scheduling calendar data between systems. Essentially this is iTip over http. The motivation was to try to provide a more immediate response to scheduling requests.

Issues we have named “the identity crisis” have held up this speciﬁcation.

It does have uses for hosts that trust each other and/or use a common authentication framework.

Bibliography

The versit vCalendar speciﬁcation: http://www.imc.org/pdi/vcal-10.txt

RFC5545 - the iCalendar speciﬁcation: https://tools.ietf.org/html/rfc5545

RFC5546 - iTip: https://tools.ietf.org/html/rfc5546

RFC 6321 - Xcal: https://tools.ietf.org/html/rfc6321

RFC 7529 - Rscale: https://tools.ietf.org/html/rfc7529

Vavailability: https://tools.ietf.org/html/draft-daboo-calendar-availability-05 iCalendar extensions: https://www.ietf.org/archive/id/draft-daboo-icalendar-extensions-09.txt