iCalendar Specification (RFC5545)

Read in PDF Format

Structure

iCalendar Format Specification in a Nutshell

The Internet Calendaring and Scheduling Core Object Specification, or iCalendar, defines a data format for representing and exchanging calendaring and scheduling information. This includes information like events, to-dos, journal entries, and free/busy information. The format is designed to be independent of any particular calendar service or protocol.

Key aspects of the iCalendar format:

• Purpose: To capture and exchange information typically stored in calendaring and scheduling applications. It is suitable as an exchange format between applications or systems.
• Structure: An iCalendar object is a collection of calendaring and scheduling information. Typically, it consists of an iCalendar stream with one or more iCalendar objects. The object is organized into content lines.
• Content Lines: These are individual lines of text delimited by a CRLF sequence (CR character followed by LF character). Lines longer than 75 octets should be split into multiple lines using a line folding technique. This involves inserting a CRLF followed immediately by a single linear white-space character (SPACE or HTAB). When processing, such sequences are ignored (unfolded) to restore the original single line.
  • A content line generally consists of a name, optional parameters separated by semicolons, and a value, separated by a colon. The line ends with CRLF.
  • Multiple values for a property can be encoded by creating a new content line for each value, including the property name, or by separating values with a COMMA character within a single property line, depending on the specific property.
• iCalendar Object Format: An iCalendar stream consists of one or more icalobjects. Each icalobject is delimited by "BEGIN:VCALENDAR" and "END:VCALENDAR" strings. The body (icalbody) consists of calendar properties that apply to the object as a whole, followed by one or more calendar components.
• Calendar Properties: These are attributes that apply to the iCalendar object as a whole. They should be specified after "BEGIN:VCALENDAR" and before any calendar component. Examples include:
  • "CALSCALE" property: Defines the calendar scale used, defaulting to "GREGORIAN".
  • "METHOD" property: Defines the iCalendar object method (e.g., "REQUEST"). If present, a scheduling transaction can be assumed; otherwise, the object is just a snapshot of calendar information. This property is the subject of other specifications like iTIP.
  • "PRODID" property: Specifies the identifier for the product that created the object. It MUST be specified once.
  • "VERSION" property: Specifies the iCalendar specification version required to interpret the object. A value of "2.0" corresponds to this memo. It MUST be specified once.
• Calendar Components: These are collections of properties that represent a specific calendar semantic, such as an event, to-do, journal entry, time zone information, free/busy time information, or an alarm. Calendar components start with the letter "V" and are referred to with capitalized, quoted-strings, like "VEVENT", "VTODO", and "VJOURNAL". They are defined using BEGIN and END delimiters followed by the component name (e.g., "BEGIN:VEVENT", "END:VEVENT").
  • An iCalendar object MUST include at least one calendar component. Commonly, it will contain a single "VEVENT", "VTODO", or "VJOURNAL" component.
  • Examples of standard components:
    • "VEVENT": Describes an event. Represents a scheduled amount of time on a calendar. Can also be used for anniversaries or daily reminders.
    • **:VEVENT", "END:VEVENT").
  • An iCalendar object MUST include at least one calendar component. Commonly, it will contain a single "VEVENT", "VTODO", or "VJOURNAL" component.
  • Examples of standard components:
    • "VEVENT": Describes an event. Represents a scheduled amount of time on a calendar. Can also be used for anniversaries or daily reminders.
    • "VTODO": Describes a to-do. Represents an action-item or assignment.
    • "VJOURNAL": Describes a journal entry. Used to capture textual journal entries.
    • "VFREEBUSY": Represents a request for free or busy time, a reply, or published busy time. Cannot be nested within another component.
  • Applications should support all component types defined and SHOULD NOT silently drop unknown components.
• Properties within Components: Components contain properties that provide specific details about the component. Property names, parameter names, and enumerated parameter values are case-insensitive. Examples of properties applicable to components:
  • "CLASS" property: Specifies the access classification (e.g., "PUBLIC", "PRIVATE", "CONFIDENTIAL"). Default is PUBLIC if not specified.
  • "COMMENT" property: Specifies non-processing information as a comment.
  • "DESCRIPTION" property: Provides a more complete textual description.
  • "LOCATION" property: Specifies information related to the location of the activity.
  • "PRIORITY" property: Defines the relative priority.
  • "RESOURCES" property: Defines equipment or resources needed.
  • "STATUS" property: Defines the status of a component (e.g., CONFIRMED for VEVENT, NEEDS-ACTION for VTODO, DRAFT for VJOURNAL).
  • "SUMMARY" property: Defines a short summary or subject.
  • "UID" property: Defines the persistent, globally unique identifier for the component. REQUIRED for VEVENT, VTODO, VJOURNAL, and VFREEBUSY components.
  • "DTSTAMP" property: The date-time stamp indicating when the object was created. REQUIRED for VEVENT, VTODO, VJOURNAL, and VFREEBUSY components.
  • "DTSTART" property: Specifies the date and time that a calendar component begins. REQUIRED for VEVENT if the iCalendar object doesn't specify the "METHOD" property.
  • "DTEND" property: Specifies the date and time that a calendar component ends.
  • "DUE" property: Specifies the date and time that a to-do is expected to be completed.
  • "ORGANIZER" property: Defines the organizer of a group-scheduled component.
  • "ATTENDEE" property: Defines an attendee in a group-scheduled component.
  • "URL" property: Specifies a URL.
  • "RELATED-TO" property: Defines a relationship or reference between one calendar component and another.
  • "REQUEST-STATUS" property: Defines the status code returned for a scheduling request.
• Property Parameters: Provide additional information about the property value. Defined with lowercase, quoted-strings followed by "parameter". Multiple parameters for a property are separated by a SEMICOLON character. Parameters with values containing COLON, SEMICOLON, or COMMA characters MUST be in quoted text. Examples include "ALTREP" for alternate text representation, "VALUE" to override the default value type, "TZID" for time zone identifier, "ENCODING" for inline binary content, "FMTTYPE" for format type, etc..
• Value Data Types: Properties have defined value types. Examples include TEXT, DATE, DATE-TIME, DURATION, FLOAT, INTEGER, URI, CAL-ADDRESS, PERIOD, RECUR, BOOLEAN, BINARY. The default value type for a property can be overridden using the "VALUE" parameter.
• Binary Content: SHOULD be referenced using a URI. If included inline, it MUST be BASE64 encoded and the "ENCODING" parameter MUST be specified.
• Internationalization: iCalendar streams MUST be generated in UTF-8 and MUST accept UTF-8 or US-ASCII charsets.
• Non-Standard Elements: The format allows for non-standard components (x-comp), properties (x-prop), and parameters (x-param) using an "X-" prefix. Vendors should concatenate a short prefix after "X-" to identify themselves. Applications MUST ignore unrecognized standard elements and MAY ignore non-standard ones.
• IANA Considerations: The specification includes processes for registering new iCalendar elements (components, properties, parameters, value data types, values) with IANA. Existing registries include components, properties, parameters, value data types, calendar user types, and more.