Sentio, ergo sum

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 product.

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.

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 stated.

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. Formating Convention

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 calendar component.

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 more.

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.

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 mechanisms.

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

   ng description

    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 object:

     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

                   / NON-US-ASCII

     ; 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 stated.