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 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 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 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 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 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 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.
Recommend
More recommend
