ICalendar
|
|
- The title of this article is incorrect because of technical limitations. The correct title is iCalendar.
iCalendar is a standard (RFC 2445) for calendar data exchange. The standard is also known as iCal, based on the application of the same name.
It is implemented/supported by a large number of products, including the Apple iCal application, Mozilla Calendar (including Mozilla Sunbird), Lotus Notes, Mulberry [1] (http://www.mulberrymail.com), Korganizer, and Ximian Evolution. Microsoft's Outlook also supports iCalendar, though there are some known problems with its support (many of which can be fixed by installing patches) [2] (http://www.slipstick.com/calendar/); in particular, Outlook 2000 users cannot process iCalendar files created by Outlook 2002 without patching because Outlook 2000 has an error in its iCalendar implementation [3] (http://support.microsoft.com/default.aspx?scid=kb;en-us;307313). Users of Outlook must configure their mail program to use open Internet standards instead of Microsoft's proprietary specifications. [4] (http://www.scheduleworld.com/outlookInteroperability.html) [5] (http://www.scheduleworld.com/configureOutlook.html) [6] (http://lists.ximian.com/archives/public/evolution/2001-August/011884.html) [7] (http://lists.ximian.com/archives/public/evolution/2001-August/011891.html)
iCalendar data is typically exchanged using traditional email, but the standard is designed to be independent of the transport protocol. For example, it can also be shared and edited by using a WebDav server. Simple web servers (using just the HTTP protocol) are often used to distribute iCalendar data about an event and to publish busy times of an individual.
| Contents |
Specification Basics
The iCalendar specification is a result of the work of the Engineering Task Force Calendaring and Scheduling Working Group (chaired by Anik Ganguly of Open Text Inc.), and was authored by Frank Dawson of Lotus Development Corporation and Derik Stenerson of Microsoft Corporation. iCalendar is heavily based on the earlier vCalendar industry specification by the Internet Mail Consortium (IMC). After iCalendar was released, IMC stated that it "hopes that all vCalendar developers take advantage of these new open standards and make their software compatible with both vCalendar 1.0 and iCalendar."
iCalendar data has the MIME content type text/calendar. The file extension of "ics" is to be used to designate a file containing (an arbitrary set of) calendaring and scheduling information consistent with this MIME content type. The file extension of "ifb" is to be used to designate a file containing free or busy time information consistent with this MIME content type. The file type code of "iCal" is to be used in Apple Macintosh operating system environments to designate a file containing calendaring and scheduling information consistent with this MIME media type. The file type code of "iFBf" is to be used in Apple Macintosh operating system environments to designate a file containing free or busy time information consistent with this MIME media type.
Core object
The top-level object in iCalendar is the Calendaring and Scheduling Core Object. This is a collection of calendaring and scheduling information. Typically, this information will consist of a single iCalendar object. However, multiple iCalendar objects can be sequentially grouped together. The first line must be "BEGIN: VCALENDAR", and the last line must be "END: VCALENDAR"; the contents between these lines is called the "icalbody". The body of the iCalendar object (the icalbody) consists of a sequence of calendar properties and one or more calendar components. The calendar properties are attributes that apply to the calendar as a whole. The calendar components are collections of properties that express a particular calendar semantic. For example, the calendar component can specify an event, a to-do, a journal entry, time zone information, or free/busy time information, or an alarm.
Here is a simple example (from RFC 2445) of an iCalendar object that defines a "Bastille Day Party" event occurring from July 14, 1997 17:00 (UTC) through July 15, 1997 03:59:59 (UTC):
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//hacksw/handcal//NONSGML v1.0//EN
BEGIN:VEVENT
DTSTART:19970714T170000Z
DTEND:19970715T035959Z
SUMMARY:Bastille Day Party
END:VEVENT
END:VCALENDAR
There are many different types of components defined in the standard, as described below.
Events (VEVENT)
A "VEVENT" component provides a grouping of component properties that describe an event that represents a scheduled amount of time on a calendar. Normally, an accepted event will cause that time to be considered busy, but an event can be set to be "TRANSPARENT" to change this interpretation. A VEVENT may include a VALARM calendar component to define alarms. Such events have a DTSTART property that defines its starting time, and a DTEND property defining its ending time. If the event is recurring, DTSTART defines the start of the first event.
Repeated events without a specific time, such as anniversaries and daily reminders, are also represented using VEVENT. These events would have a DATE value type for the "DTSTART" property instead of the default DATE-TIME, and need not include a "DTEND" property.
To-do (VTODO)
The VTODO component describes a to-do item, i.e., an action-item or assignment.
The following is an example of a to-do due on April 15, 1998, from RFC 2445. An audio alarm has been specified to remind the calendar user at noon, the day before the to-do is expected to be completed and repeat hourly, four additional times. The to-do definition has been modified twice since it was initially created.
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VTODO
DTSTAMP:19980130T134500Z
SEQUENCE:2
UID:uid4@host1.com
ORGANIZER:MAILTO:unclesam@us.gov
ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@host.com
DUE:19980415T235959
STATUS:NEEDS-ACTION
SUMMARY:Submit Income Taxes
BEGIN:VALARM
ACTION:AUDIO
TRIGGER:19980403T120000
ATTACH;FMTTYPE=audio/basic:http://host.com/pub/audio-
files/ssbanner.aud
REPEAT:4
DURATION:PT1H
END:VALARM
END:VTODO
END:VCALENDAR
Journal entry (VJOURNAL)
VJOURNAL components describe a journal entry. They simply attach descriptive text notes with a particular calendar date, and might be used to record a daily record of activities or accomplishments. A "VJOURNAL" calendar component does not take up time on, so it has no affect on free or busy time (just like TRANSPARENT entries). In practice, few implementations of iCalendar support VJOURNAL entries.
The following is an example of a journal entry, from RFC 2445:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VJOURNAL
DTSTAMP:19970324T120000Z
UID:uid5@host1.com
ORGANIZER:MAILTO:jsmith@host.com
STATUS:DRAFT
CLASS:PUBLIC
CATEGORY:Project Report, XYZ, Weekly Meeting
DESCRIPTION:Project xyz Review Meeting Minutes\n
Agenda\n1. Review of project version 1.0 requirements.\n2.
Definition
of project processes.\n3. Review of project schedule.\n
Participants: John Smith, Jane Doe, Jim Dandy\n-It was
decided that the requirements need to be signed off by
product marketing.\n-Project processes were accepted.\n
-Project schedule needs to account for scheduled holidays
and employee vacation time. Check with HR for specific
dates.\n-New schedule will be distributed by Friday.\n-
Next weeks meeting is cancelled. No meeting until 3/23.
END:VJOURNAL
END:VCALENDAR
Free/busy time (VFREEBUSY)
A VFREEBUSY component describes either a request for free/busy time, describes a response to a request, or describes a published set of busy time.
As described in RFC 2445:
When used to request free/busy time information, the "ATTENDEE" property specifies the calendar users whose free/busy time is being requested; the "ORGANIZER" property specifies the calendar user who is requesting the free/busy time; the "DTSTART" and "DTEND" properties specify the window of time for which the free/busy time is being requested; the "UID" and "DTSTAMP" properties are specified to assist in proper sequencing of multiple free/busy time requests.
When used to reply to a request for free/busy time, the "ATTENDEE" property specifies the calendar user responding to the free/busy time request; the "ORGANIZER" property specifies the calendar user that originally requested the free/busy time; the "FREEBUSY" property specifies the free/busy time information (if it exists); and the "UID" and "DTSTAMP" properties are specified to assist in proper sequencing of multiple free/busy time replies.
When used to publish busy time, the "ORGANIZER" property specifies the calendar user associated with the published busy time; the "DTSTART" and "DTEND" properties specify an inclusive time window that surrounds the busy time information; the "FREEBUSY" property specifies the published busy time information; and the "DTSTAMP" property specifies the date/time that iCalendar object was created.
The following is an example of published busy time information from RFC 2445. The iCalendar object might be placed at some URL with the extension ".ifb":
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//RDU Software//NONSGML HandCal//EN
BEGIN:VFREEBUSY
ORGANIZER:MAILTO:jsmith@host.com
DTSTART:19980313T141711Z
DTEND:19980410T141711Z
FREEBUSY:19980314T233000Z/19980315T003000Z
FREEBUSY:19980316T153000Z/19980316T163000Z
FREEBUSY:19980318T030000Z/19980318T040000Z
URL:http://www.host.com/calendar/busytime/jsmith.ifb
END:VFREEBUSY
END:VCALENDAR
Other component types
Other component types defined by the standard include VTIMEZONE (for defining time zones) and VALARM (for defining alarms). Note that some components can include other components (VALARM is often included in other components), and some components are often defined to support other components defined after them (VTIMEZONE is often used this way).
iCalendar Data Exchange
The iCalendar format is designed to describe calendar-based data (like events), and intentionally does not describe what to do with that data. Thus, other protocols may be needed to negotiate what to do with this data.
A companion standard, "iCalendar Transport-Independent Interoperability" (iTIP) (RFC 2446), defines a protocol for exchanging iCalendar objects for the purposes of group calendaring and scheduling between "Calendar Users" (CUs); whoever initiates the exchange of data takes on the role of the "Organizer". This standard defines methods such as PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER (to negotiate a change in the entry), and DECLINE-COUNTER (to decline the counter-proposal).
Another companion standard, "iCalendar Message-based Interoperability Protocol (IMIP)" (RFC 2447), defines a standard method for implementing iTIP on standard Internet email-based transports.
The "Guide to Internet Calendaring" (RFC 3283) describes the relationship of iCalendar to various related standards (current and future).
The iCalendar format was designed to support interoperability of calendar data; while the features most often used by users are widely supported by iCalendar implementations and can be exchanged, interoperation between implementations of some more advanced capabilities is spotty. Most vendors do not support Journals (VJOURNAL). Recurring and repeating meetings still have a "bit of mystery and ambiguity associated with them", causing some interoperability problems in some cases. VTODO's have had interoperability problems as well. (University of California at Berkeley, 2004).
A "Calendar Access Protocol" (CAP) standard has been in development to provide standardized immediate interactive access to others' calendars, subject to various access control restrictions. The IETF Calendaring and Scheduling (calsch) Working Group (http://www.imc.org/ietf-calendar/index.html) has in the past worked on various extensions to, and supporting protocols for, iCalendar. Officially the working group has been closed in September 2004 as an IETF working group (so that it can be reorganized); its mailing list continues to be used for calendar-related discussions. [8] (http://www.imc.org/ietf-calendar/mail-archive/msg17988.html) [9] (http://www.imc.org/ietf-calendar/mail-archive/msg18032.html)
See also
External links
- Internet Calendaring and Scheduling Core Object Specification (iCalendar) - RFC 2445 (http://www.faqs.org/rfcs/rfc2445.html) - IETF. November 1998
- Article "Microsoft Outlook Interoperability with RFC2445 (http://www.scheduleworld.com/outlookInteroperability.html)" by Mark Swanson
- Dawson, F., Mansour, S. and S. Silverberg, "iCalendar Message-based Interoperability Protocol (IMIP)", RFC 2447, November 1998.
- Silverberg, S., Mansour, S., Dawson, F. and R. Hopson, "iCalendar Transport-Independent Interoperability Protocol (iTIP) : Scheduling Events, Busy Time, To-dos and Journal Entries", RFC 2446, November 1998.
- Internet Mail Consortium (IMC). "Personal Data Interchange: vCard and vCalendar" (http://www.imc.org/pdi/). This describes the relationship of vCard, vCalendar, and iCalendar, and includes IMC's request for implementors to support both vCalendar and iCalendar.
- "Guide to Internet Calendaring". RFC 3283.
- University of California at Berkeley July 28-30, 2004. Calconnect IV Interoperability Testing of RFC 2445, RFC 2446 and RFC 2447 (http://www.calconnect.org/interop/uc%20berkeley%20interop%20testing.pdf)
- iCalendar DTD Document (xCal) (http://xml.coverpages.org/iCal.html)
- Article "Rich Clients for Web Services (http://java.sun.com/features/2001/06/golden.clients.html)" by Thomas Ulrich
- Support for iCalendar and vCard in Domino (http://www-1.ibm.com/support/docview.wss?uid=swg21102862)
- iCalendar Files on Mac OS X (http://developer.apple.com/internet/appleapplications/icalendarfiles.html)
- iCal::Parser (http://search.cpan.org/~rfrankel/iCal-Parser/lib/iCal/Parser.pm) by Rick Frankel
- iCal4j (http://ical4j.sourceforge.net/)
- JiCal - Java iCalendar Toolset (http://co-project.lboro.ac.uk/users/coch2/jical-1.4/docs/html/) and Group Scheduler (http://jical.sourceforge.net/) by Stuart Guthrie
- hCalendar (http://developers.technorati.com/wiki/hCalendar)