|Introduction | Sustainability Factors | Content Categories | Format Descriptions | Contact|
|Full name||iCalendar Electronic Calendar and Scheduling Format|
iCalendar, or iCal, is a widely-used format for the exchange of electronic calendaring and scheduling data between applications or systems. Based on the vCalendar format created by the Internet Mail Consortium, iCalendar files can be exchanged through a wide variety of methods including SMTP, HTTP, interactive desktop protocols such as the use of a memory-based clipboard or drag/drop interactions, and others because they are designed to be independent of specific transport protocols. The iCalendar format supports functionality such as requesting, replying to, modifying, and canceling meetings or appointments, to-dos, and journal entries. Through the iCalendar Transport-independent Interoperability Protocol (iTIP) defined in RFC 2446, iCalendar objects can be used to define other calendaring and scheduling operations such as requesting for and replying with free/busy time data.
See Notes for description of the file structure.
|Relationship to other formats|
|Has subtype||hCalendar, HTML Electronic Calendar and Scheduling Format. HTML representation of iCal calendar information|
|LC experience or existing holdings|
Open standards available from Internet Engineering Task Force (IETF).
iCalendar is fully documented though RFC 5545, RFC 2446, and RFC 2447.
According to Wikipedia (accessed on May 1, 2014), "iCalendar is used and supported by a large number of products, including Google Calendar, Apple Calendar (formerly iCal), IBM Lotus Notes, Yahoo! Calendar, Evolution (software), eM Client, Lightning extension for Mozilla Thunderbird and SeaMonkey, and partially by Microsoft Outlook and Novell GroupWise."
The iCalendar implementation page on Microformats.com provides details about some modifications for specific implementations including Apple iCal 2.0.5 (date and date-time formatting) and Microsoft Outlook 2003 (where the VEVENTS calendar component is required to have UID, DTSTAMP, and METHOD properties or an error is returned).
|Licensing and patents||None|
The primary content of iCalendar files is straightforward text that can be read by humans or processed by computers. An iCalendar file consists of lines of text, each line limited to 75 octets and delimited by a CRLF sequence. The default character encoding is UTF-8. To facilitate automated parsing, RFC 5545 defines the iCalendar format using ABNF notation, as defined in RFC 5234.
Applications must also read, but are not required to write, US-ASCII.
Calendar objects, such as events, may have binary attachments encoded using the BASE64 encoding defined in RFC 4648 and embedded inline.
iCalendar has syntax and structure that features well-defined metadata. See Notes for description of the file structure.
|Technical protection considerations||None|
"ics" is used to designate a file containing calendaring and scheduling information consistent with text/calendar MIME content type.
"ifb" is used to designate a file containing free or busy time information consistent with text/calendar MIME content type.
|Internet Media Type||text/calendar
Registered with IANA
|Mac OS file type||iCal
"iCal" is used to designate a file containing calendaring and scheduling information consistent with text/calendar MIME media type.
"iFBf" is used to designate a file containing free or busy time information consistent with text/calendar MIME media type.
||PRONOM entry for Internet Calendar and Scheduling format. Identification based on internal signifier.|
At the most basic level, iCalendar files are organized into individual lines of text (called content lines) which are limited to 75 octets in length. Content lines are delimited by a CRLF sequence. Long data items (i.e., longer than 75 octets) can be split between any two characters by inserting a CRLF immediately followed by a single SPACE or TAB white-space character.
At a higher level of structure, the Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. Typically, this information will consist of an iCalendar stream with a one or more sequentially grouped iCalendar objects together in an iCalendar stream.
Within the iCalendar object, the first line must be "BEGIN:VCALENDAR" and the last line must be "END:VCALENDAR". Between these encapsulating lines is the iCalendar body which consists of a sequence of calendar properties and one or more calendar components. The calendar properties are attributes that apply to the calendar object 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, free/busy time information, or an alarm.
Within the iCalendar body structure:
Applications that import iCalendar objects are expected to support all of the component types defined in RFC 5545. Practically, this means that applications are expected to ignore values they don't recognize and should not silently drop any components as that can lead to user data loss.
Moreover, compliant applications must generate iCalendar streams in the UTF-8 charset and must accept iCalendar streams in UTF-8 or US-ASCII charsets. A different character set can be specified using the "charset" MIME parameter.
iCalendar objects can have attachments. The default value type for the Attach descriptive component property is URI. The value type can also be set to BINARY to indicate inline binary encoded content information.
iCalendar is based on the vCalendar format published in 1996 by the Internet Mail Consortium (IMC). RFC 2445, which defined the first iCalendar format, was created by the Internet Engineering Task Force Calendaring and Scheduling Working Group in 1998; the RFC 5545 update and current specification was published by IETF in 2009.