Calendaring The standards and protocols A brief history It started - - PDF document

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 defining 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 defined 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 defined how events and tasks can be used to schedule meetings and tasks and RFC 2447 defined 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 specific 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 specification 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 notifications, resource-sharing, calendar-sharing
• VPOLL
• iSchedule

Calendar Data Structure

iCalendar - RFC 5545

This is the mother specification - where it all starts.

Components

This specification defines the following components:

• VCALENDAR - to contain one or more of the rest
• VTIMEZONE - a representation of a timezone specification
• 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 specification defines 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 define 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 specification for the timezone along with the events/tasks. Most of these are

• nly 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 significant 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

• f 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 specified instance.

Instances are identified 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. Defined for use in Ws-Calendar and the smart-

• grid. 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 defined 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 fine. 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

• f 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 first 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 first - 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

• r 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-defined component - VPOLL.

VPOLL

This component contains a number of choices and identifies 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 defines a period, perhaps infinite 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 - defining periods of time in which produces can provide certain amounts of power or defining 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 specification 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 (specification 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

• ver 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 specification. It does have uses for hosts that trust each other and/or use a common authentication framework.

Bibliography

The versit vCalendar specification: http://www.imc.org/pdi/vcal-10.txt RFC5545 - the iCalendar specification: 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