Internet Calendaring and Scheduling Core Object Specification (iCalendar)
obsoletes
- rfc-2445 — Internet Calendaring and Scheduling Core Object Specification (iCalendar)
updated by
- rfc-5546 — iCalendar Transport-Independent Interoperability Protocol (iTIP)
- rfc-6868 — Parameter Value Encoding in iCalendar and vCard
- rfc-7529 — Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar)
- rfc-7953 — Calendar Availability
- rfc-7986 — New Properties for iCalendar
- rfc-9073 — Event Publishing Extensions to iCalendar
- rfc-9074 — "VALARM" Extensions for iCalendar
- rfc-9253 — Support for iCalendar Relationships
Extracted elements (29)
Floating time (DATE-TIME without TZID or UTC designator) is defined to represent the same clock time regardless of which timezone an attendee is in — useful for events like 'busy 11 AM–1 PM every day everywhere'. The spec notes that two attendees in different timezones receiving the same floating event may attend at different actual UTC instants, so floating time SHOULD only be used where that behavior is intentional.
iCalendar intentionally does not define a global time zone name registry, leaving TZID identifiers implementation-defined. The SOLIDUS prefix on a TZID is reserved to indicate a future globally registered identifier. Implementors are encouraged to use the public-domain TZ database (Olson database) naming conventions in the interim.
RFC 5545 obsoletes RFC 2445. Key changes include: deprecation of THISANDPRIOR range parameter, clarification of VTIMEZONE component requirements, new restrictions on UNTIL/DTSTART type matching, and updated IANA registration procedures. Implementations must be prepared to receive objects conforming to RFC 2445.
The RANGE parameter value 'THISANDPRIOR' is deprecated by RFC 5545 and MUST NOT be generated by applications. Only 'THISANDFUTURE' is a valid RANGE parameter value. This is a breaking change from RFC 2445.
Applications MUST ignore x-param and iana-param property parameter values they do not recognize, preserving the value data without attempting to interpret or parse it.
Binary content information in an iCalendar object SHOULD be referenced using a URI. When included inline, it MUST be BASE64-encoded and the property MUST specify the 'ENCODING=BASE64' parameter. Inline binary SHOULD only be used when the object must be expressed as a single entity.
Multi-valued properties MUST NOT be used to specify multiple language variants of the same value. Calendar applications SHOULD display all values when a property has multiple values. Individual property definitions must be consulted to determine which encoding form (multiple content lines vs. COMMA-separated) is allowed.
Property parameter values that contain a COLON, SEMICOLON, or COMMA character MUST be placed in quoted-string text. Property parameter values MUST NOT contain the DQUOTE character except as delimiters.
The default character set for an iCalendar stream is UTF-8 as defined in RFC 3629. When transported as a MIME entity, the 'charset' Content-Type parameter MUST be used to specify the charset being used.
The TZID parameter MUST be specified on DTSTART, DTEND, DUE, EXDATE, and RDATE properties when the value is a DATE-TIME or TIME that is neither UTC nor floating time. A separate VTIMEZONE component MUST be present for each unique TZID parameter value in the iCalendar object.
The UNTIL rule part value MUST have the same value type as the DTSTART property. If DTSTART is specified as a date with UTC time or local time with timezone reference, then UNTIL MUST be specified as a date with UTC time. In STANDARD and DAYLIGHT sub-components, UNTIL MUST always be UTC.
When parsing a content line, folded lines MUST first be unfolded by removing the CRLF and the immediately following linear white-space character. Implementations must take care not to split UTF-8 multi-octet sequences across fold boundaries.
The ATTENDEE property conveys the calendar address of a participant in a group-scheduled calendar component. It supports parameters including CN, CUTYPE, DELEGATED-FROM, DELEGATED-TO, DIR, LANGUAGE, MEMBER, PARTSTAT, ROLE, RSVP, SENT-BY. The value MUST be a CAL-ADDRESS (URI, typically mailto:).
The FREEBUSY component property (VFREEBUSY) defines one or more free or busy time intervals. The FBTYPE parameter qualifies each interval as FREE, BUSY, BUSY-UNAVAILABLE, or BUSY-TENTATIVE. FREEBUSY property values MUST be specified as UTC time and sorted in ascending order.
The RECURRENCE-ID property is used to identify a particular instance of a recurring calendar component. It is used in conjunction with the UID and SEQUENCE properties to identify a particular recurrence instance for updating or deletion. The RANGE parameter with value THISANDFUTURE indicates the modification applies to the identified instance and all subsequent instances.
The RRULE property defines a rule or repeating pattern for recurring events, to-dos, journal entries, or timezone definitions. The value is a RECUR type. Only one RRULE SHOULD be specified; the behavior when multiple RRULE properties are specified is undefined.
The SEQUENCE property defines the revision sequence number of the calendar component within a sequence of revisions. It MUST be incremented each time the organizer makes a significant revision to the calendar component. Attendees returning a REPLY use the SEQUENCE value to identify which version they are responding to.
The UID property provides a globally unique identifier for a calendar component. It MUST be present in VEVENT, VTODO, VJOURNAL, and VFREEBUSY components. The value is a text string that SHOULD be generated using a globally unique algorithm such as one based on an Internet mail address.
The VALARM component is a grouping of properties that define an alarm or reminder associated with a VEVENT or VTODO. It MUST include ACTION (AUDIO, DISPLAY, EMAIL) and TRIGGER properties. REPEAT and DURATION MUST both be present if either is present.
The VEVENT component represents a scheduled amount of time on a calendar. It requires DTSTART and either DTEND or DURATION (not both). Optional properties include SUMMARY, DESCRIPTION, LOCATION, ORGANIZER, ATTENDEE, RRULE, RECURRENCE-ID, SEQUENCE, UID, and others. VEVENT MUST contain exactly one DTSTART when specified.
The VTIMEZONE component defines a timezone used in the iCalendar object. It MUST contain a TZID property and at least one STANDARD or DAYLIGHT sub-component, each with DTSTART, TZOFFSETFROM, and TZOFFSETTO properties. Multiple STANDARD/DAYLIGHT sub-components can represent historical timezone changes.
The VTODO component represents a to-do task. It supports DTSTART, DUE or DURATION (not both), COMPLETED, PERCENT-COMPLETE, and STATUS values specific to tasks (NEEDS-ACTION, IN-PROCESS, COMPLETED, CANCELLED). Unlike VEVENT, VTODO instances without a specified duration are considered to have zero duration.
RFC 5545 creates IANA registries for iCalendar elements: Components (VEVENT, VTODO, VJOURNAL, VFREEBUSY, VTIMEZONE, VALARM), Properties (~50 properties), Parameters (20 parameters), Value Data Types (14 types), Calendar User Types, Free/Busy Time Types, Participation Statuses, Relationship Types, Participation Roles, Actions, Classifications, and Methods. Registration requires IETF Review.
RFC 5545 registers the 'text/calendar' media type with IANA. The 'method' parameter optionally specifies the iCalendar object method (e.g., REQUEST, REPLY, CANCEL) as defined by iTIP. The default charset is UTF-8.
iCalendar objects can contain attachments via URI or inline binary, which may expose recipients to malicious content. The format includes no built-in authentication or integrity mechanisms; implementors should use external security mechanisms such as S/MIME or PGP when authenticity or confidentiality is required. The 'METHOD' property can be used to drive scheduling operations that may have significant consequences (e.g., meeting cancellations).
Each iCalendar content line has the form 'name *(";" param) ":" value CRLF'. Property names and parameter names are case-insensitive; property values are case-sensitive unless stated otherwise. Lines SHOULD NOT exceed 75 octets (excluding the line break) and SHOULD be folded by inserting CRLF followed by a single linear white-space character.
The DATE-TIME value type supports three forms: (1) local/floating time 'YYYYMMDDTHHmmss' with no timezone suffix, (2) UTC time 'YYYYMMDDTHHmmssZ' with a trailing 'Z', and (3) local time with a TZID parameter reference. The form with a UTC offset (e.g., '-0800') MUST NOT be used.
The DATE value type is encoded as 'YYYYMMdd' (4-digit year, 2-digit month, 2-digit day) with no separator characters, based on ISO 8601 basic format. The DURATION type uses 'P' prefix followed by designators: 'nW' for weeks, 'nD' for days, 'T' separator, 'nH' for hours, 'nM' for minutes, 'nS' for seconds. Year and month designators are not supported.
The RECUR (recurrence rule) value type consists of NAME=VALUE parts separated by semicolons. The FREQ part (SECONDLY/MINUTELY/HOURLY/DAILY/WEEKLY/MONTHLY/YEARLY) is REQUIRED and MUST NOT occur more than once. UNTIL and COUNT are OPTIONAL but MUST NOT both be present. For backward compatibility, FREQ MUST be the first rule part specified.