Network Working Group B. Desruisseaux, Ed.
Request for Comments: 5545 Oracle
Obsoletes: 2445 September 2009
Category: Standards Track
Internet Calendaring and Scheduling Core Object Specification
This document defines the iCalendar data format for representing and
exchanging calendaring and scheduling information such as events,
to-dos, journal entries, and free/busy information, independent of any
particular calendar service or protocol.
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright and License Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16310. References . . . . . . . . . . . . . . . . . . . . . . . . . 16410.1. Normative References . . . . . . . . . . . . . . . . . . 16410.2. Informative References . . . . . . . . . . . . . . . . . 165
Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 167A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . 167A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . 167A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 1671. Introduction
The use of calendaring and scheduling has grown considerably in the
last decade. Enterprise and inter-enterprise business has become
dependent on rapid scheduling of events and actions using this
information technology. This memo is intended to progress the level
of interoperability possible between dissimilar calendaring and
scheduling applications. This memo defines a MIME content type for
exchanging electronic calendaring and scheduling information. The
Internet Calendaring and Scheduling Core Object Specification, or
iCalendar, allows for the capture and exchange of information
normally stored within a calendaring and scheduling application; such
as a Personal Information Manager (PIM) or a Group-Scheduling
The iCalendar format is suitable as an exchange format between
applications or systems. The format is defined in terms of a MIME
content type. This will enable the object to be exchanged using
several transports, including but not limited to SMTP, HTTP, a file
system, desktop interactive protocols such as the use of a memory-
based clipboard or drag/drop interactions, point-to-point
asynchronous communication, wired-network transport, or some form of
unwired transport such as infrared.
The memo also provides for the definition of iCalendar object methods
that will map this content type to a set of messages for supporting
calendaring and scheduling operations such as requesting, replying
to, modifying, and canceling meetings or appointments, to-dos, and
journal entries. The iCalendar object methods can be used to define
other calendaring and scheduling operations such as requesting for
and replying with free/busy time data. Such a scheduling protocol is
defined in the iCalendar Transport-independent Interoperability
Protocol (iTIP) defined in [2446bis].
The memo also includes a formal grammar for the content type based on
the Internet ABNF defined in [RFC5234]. This ABNF is required for
the implementation of parsers and to serve as the definitive
reference when ambiguities or questions arise in interpreting the
descriptive prose definition of the memo. Additional restrictions
that could not easily be expressed with the ABNF syntax are specified
as comments in the ABNF. Comments with normative statements should
be treated as such.
2. Basic Grammar and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This memo makes use of both a descriptive prose and a more formal
notation for defining the calendaring and scheduling format.
The notation used in this memo is the ABNF notation of [RFC5234].
Readers intending on implementing the format defined in this memo
should be familiar with this notation in order to properly interpret
the specifications of this memo.
All numeric values used in this memo are given in decimal notation.
All names of properties, property parameters, enumerated property
values, and property parameter values are case-insensitive. However,
all other property values are case-sensitive, unless otherwise
Note: All indented editorial notes, such as this one, are intended
to provide the reader with additional information. The
information is not essential to the building of an implementation
conformant with this memo. The information is provided to
highlight a particular feature or characteristic of the memo.
The format for the iCalendar object is based on the syntax of the
text/directory media type [RFC2425]. While the iCalendar object is
not a profile of the text/directory media type [RFC2425], it does
reuse a number of the elements from the [RFC2425] specification.
2.1. Formatting Conventions
The elements defined in this memo are defined in prose. Many of the
terms used to describe these have common usage that is different than
the standards usage of this memo. In order to reference, within this
memo, elements of the calendaring and scheduling model, core object
(this memo), or interoperability protocol [2446bis] some formatting
conventions have been used. Calendaring and scheduling roles are
referred to in quoted-strings of text with the first character of
each word in uppercase. For example, "Organizer" refers to a role of
a "Calendar User" within the scheduling protocol defined by
[2446bis]. Calendar components defined by this memo are referred to
with capitalized, quoted-strings of text. All calendar components
start with the letter "V". For example, "VEVENT" refers to the event
calendar component, "VTODO" refers to the to-do calendar component,
and "VJOURNAL" refers to the daily journal calendar component.
Scheduling methods defined by iTIP [2446bis] are referred to with
capitalized, quoted-strings of text. For example, "REQUEST" refers
to the method for requesting a scheduling calendar component be
created or modified, and "REPLY" refers to the method a recipient of
a request uses to update their status with the "Organizer" of the
The properties defined by this memo are referred to with capitalized,
quoted-strings of text, followed by the word "property". For
example, "ATTENDEE" property refers to the iCalendar property used to
convey the calendar address of a calendar user. Property parameters
defined by this memo are referred to with lowercase, quoted-strings
of text, followed by the word "parameter". For example, "value"
parameter refers to the iCalendar property parameter used to override
the default value type for a property value. Enumerated values
defined by this memo are referred to with capitalized text, either
alone or followed by the word "value". For example, the "MINUTELY"
value can be used with the "FREQ" component of the "RECUR" value type
to specify repeating components based on an interval of one minute or
The following table lists the different characters from the
[US-ASCII] character set that is referenced in this document. For
each character, the table specifies the character name used
throughout this document, along with its US-ASCII decimal codepoint.
| Character name | Decimal codepoint |
| HTAB | 9 |
| LF | 10 |
| CR | 13 |
| DQUOTE | 22 |
| SPACE | 32 |
| PLUS SIGN | 43 |
| COMMA | 44 |
| HYPHEN-MINUS | 45 |
| PERIOD | 46 |
| SOLIDUS | 47 |
| COLON | 58 |
| SEMICOLON | 59 |
| LATIN CAPITAL LETTER N | 78 |
| LATIN CAPITAL LETTER T | 84 |
| LATIN CAPITAL LETTER X | 88 |
| LATIN CAPITAL LETTER Z | 90 |
| BACKSLASH | 92 |
| LATIN SMALL LETTER N | 110 |
2.2. Related Memos
Implementers will need to be familiar with several other memos that,
along with this memo, form a framework for Internet calendaring and
scheduling standards. This memo specifies a core specification of
objects, value types, properties, and property parameters.
o iTIP [2446bis] specifies an interoperability protocol for
scheduling between different implementations;
o iCalendar Message-Based Interoperability Protocol (iMIP) [2447bis]
specifies an Internet email binding for [2446bis].
This memo does not attempt to repeat the specification of concepts or
definitions from these other memos. Where possible, references are
made to the memo that provides for the specification of these
concepts or definitions.
3. iCalendar Object Specification
The following sections define the details of a Calendaring and
Scheduling Core Object Specification. The Calendaring and Scheduling
Core Object is a collection of calendaring and scheduling
information. Typically, this information will consist of an
iCalendar stream with one or more iCalendar objects. The body of the
iCalendar object consists of a sequence of calendar properties and
one or more calendar components.
Section 3.1 defines the content line format; Section 3.2 defines the
property parameter format; Section 3.3 defines the data types for
property values; Section 3.4 defines the iCalendar object format;
Section 3.5 defines the iCalendar property format; Section 3.6
defines the calendar component format; Section 3.7 defines calendar
properties; and Section 3.8 defines calendar component properties.
This information is intended to be an integral part of the MIME
content type registration. In addition, this information can be used
independent of such content registration. In particular, this memo
has direct applicability for use as a calendaring and scheduling
exchange format in file-, memory-, or network-based transport
3.1. Content Lines
The iCalendar object is organized into individual lines of text,
called content lines. Content lines are delimited by a line break,
which is a CRLF sequence (CR character followed by LF character).
Lines of text SHOULD NOT be longer than 75 octets, excluding the line
break. Long content lines SHOULD be split into a multiple line
representations using a line "folding" technique. That is, a long
line can be split between any two characters by inserting a CRLF
immediately followed by a single linear white-space character (i.e.,
SPACE or HTAB). Any sequence of CRLF followed immediately by a
single linear white-space character is ignored (i.e., removed) when
processing the content type.
For example, the line:
DESCRIPTION:This is a long description that exists on a long line.
Can be represented as:
DESCRIPTION:This is a lo
that exists on a long line.
The process of moving from this folded multiple-line representation
to its single-line representation is called "unfolding". Unfolding
is accomplished by removing the CRLF and the linear white-space
character that immediately follows.
When parsing a content line, folded lines MUST first be unfolded
according to the unfolding procedure described above.
Note: It is possible for very simple implementations to generate
improperly folded lines in the middle of a UTF-8 multi-octet
sequence. For this reason, implementations need to unfold lines
in such a way to properly restore the original sequence.
The content information associated with an iCalendar object is
formatted using a syntax similar to that defined by [RFC2425]. That
is, the content information consists of CRLF-separated content lines.
The following notation defines the lines of content in an iCalendar
contentline = name *(";" param ) ":" value CRLF
; This ABNF is just a general definition for an initial parsing
; of the content line into its property name, parameter list,
; and value string
; When parsing a content line, folded lines MUST first
; be unfolded according to the unfolding procedure
; described above. When generating a content line, lines
; longer than 75 octets SHOULD be folded according to
; the folding procedure described above.
name = iana-token / x-name
iana-token = 1*(ALPHA / DIGIT / "-")
; iCalendar identifier registered with IANA
x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
; Reserved for experimental use.
vendorid = 3*(ALPHA / DIGIT)
; Vendor identification
param = param-name "=" param-value *("," param-value)
; Each property defines the specific ABNF for the parameters
; allowed on the property. Refer to specific properties for
; precise parameter ABNF.
param-name = iana-token / x-name
param-value = paramtext / quoted-string
paramtext = *SAFE-CHAR
value = *VALUE-CHAR
quoted-string = DQUOTE *QSAFE-CHAR DQUOTE
QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII
; Any character except CONTROL and DQUOTE
SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E
; Any character except CONTROL, DQUOTE, ";", ":", ","
VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII
; Any textual character
NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4
; UTF8-2, UTF8-3, and UTF8-4 are defined in [RFC3629]
CONTROL = %x00-08 / %x0A-1F / %x7F
; All the controls except HTAB
The property value component of a content line has a format that is
property specific. Refer to the section describing each property for
a definition of this format.
All names of properties, property parameters, enumerated property
values and property parameter values are case-insensitive. However,
all other property values are case-sensitive, unless otherwise
3.1.1. List and Field Separators
Some properties and parameters allow a list of values. Values in a
list of values MUST be separated by a COMMA character. There is no
significance to the order of values in a list. For those parameter
values (such as those that specify URI values) that are specified in
quoted-strings, the individual quoted-strings are separated by a
Some property values are defined in terms of multiple parts. These
structured property values MUST have their value parts separated by a
Some properties allow a list of parameters. Each property parameter
in a list of property parameters MUST be separated by a SEMICOLON
Property parameters with values containing a COLON character, a
SEMICOLON character or a COMMA character MUST be placed in quoted
For example, in the following properties, a SEMICOLON is used to
separate property parameters from each other and a COMMA character is
used to separate property values in a value list.
3.1.2. Multiple Values
Some properties defined in the iCalendar object can have multiple
values. The general rule for encoding multi-valued items is to
simply create a new content line for each value, including the
property name. However, it should be noted that some properties
support encoding multiple values in a single property by separating
the values with a COMMA character. Individual property definitions
should be consulted for determining whether a specific property
allows multiple values and in which of these two forms. Multi-valued
properties MUST NOT be used to specify multiple language variants of
the same value. Calendar applications SHOULD display all values.
3.1.3. Binary Content
Binary content information in an iCalendar object SHOULD be
referenced using a URI within a property value. That is, the binary
content information SHOULD be placed in an external MIME entity that
can be referenced by a URI from within the iCalendar object. In
applications where this is not feasible, binary content information
can be included within an iCalendar object, but only after first
encoding it into text using the "BASE64" encoding method defined in
[RFC4648]. Inline binary content SHOULD only be used in applications
whose special circumstances demand that an iCalendar object be
expressed as a single entity. A property containing inline binary
content information MUST specify the "ENCODING" property parameter.
Binary content information placed external to the iCalendar object
MUST be referenced by a uniform resource identifier (URI).
The following example specifies an "ATTACH" property that references
an attachment external to the iCalendar object with a URI reference:
The following example specifies an "ATTACH" property with inline
binary encoded content information:
3.1.4. Character Set
There is not a property parameter to declare the charset used in a
property value. The default charset for an iCalendar stream is UTF-8
as defined in [RFC3629].
The "charset" Content-Type parameter MUST be used in MIME transports
to specify the charset being used.