ietf-corpus

rfc-2445

Internet Calendaring and Scheduling Core Object Specification (iCalendar)

F. Dawson, D. Stenerson
date1998-11 streamIETF areaapp wgcalsch statusPROPOSED STANDARD pages148 canonicalhttps://www.rfc-editor.org/rfc/rfc2445 doi10.17487/RFC2445 errataview
This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across the Internet. [STANDARDS-TRACK]

obsoleted by

Extracted elements (31)

design-rationale §4.3.5

Floating time (DATE-TIME without UTC designator or TZID) represents the same hour/minute/second regardless of time zone — for example, 'busy 11 AM to 1 PM daily in any time zone.' Floating time SHOULD only be used where that semantics is actually desired; fixed times MUST use UTC or local-with-TZID.

design-rationale §4.1.4

The default character set for an iCalendar object is UTF-8 (RFC 2279). There is no per-property character set parameter; the MIME 'charset' Content-Type parameter applies to the entire body part. Use of non-US-ASCII-compatible character sets is NOT recommended.

design-rationale §3.2

The 'optinfo' MIME parameter MAY only convey semantics already present in the parsed iCalendar body and consistent with it — for example, conveying an Attendee's response status. It cannot introduce new semantics or override the body, ensuring that parsing the body part always produces an authoritative result.

interoperability-note §3.6

The iCalendar format is based on the earlier vCalendar (VCAL) industry specification and reuses elements from RFC 2425, though iCalendar is not a profile of RFC 2425. It is designed to be transport-independent: usable over SMTP, HTTP, file systems, clipboard, drag/drop, and point-to-point links.

email

normative-requirement §4.2.19 MUST

An individual VTIMEZONE calendar component MUST be specified for each unique TZID parameter value referenced within the iCalendar object. A SOLIDUS prefix on a TZID value indicates membership in a globally defined time zone registry.

normative-requirement §4.1.3 SHOULD

Binary content information in an iCalendar object SHOULD be referenced using a URI within a property value. If inline binary is necessary, it MUST be encoded using BASE64 (RFC 2045), the ENCODING property parameter MUST be specified, and binary content external to the object MUST be referenced by a URI.

normative-requirement §4.2.7 MUST

If a property's value type is VALUE=BINARY, the inline encoding parameter MUST be specified as ENCODING=BASE64. No additional BACKSLASH character encoding is defined for the BINARY value type.

normative-requirement §4.1 SHOULD

Lines of text SHOULD NOT be longer than 75 octets, excluding the line break. Long lines SHOULD be folded by inserting a CRLF immediately followed by a single linear white space character (SPACE or HTAB) between any two characters.

normative-requirement §4.2 MUST

Property parameter values that contain COLON, SEMICOLON, or COMMA characters MUST be specified as quoted-string text values. Property parameter values MUST NOT contain the DOUBLE-QUOTE character; DOUBLE-QUOTE is used solely as a quoted-string delimiter.

normative-requirement §3.2 MUST

The 'method' MIME content-type parameter MUST be the same value as the METHOD component property in the iCalendar object. If one is present, the other MUST also be present.

normative-requirement §4.2.19 MUST

The TZID property 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. The TZID parameter MUST NOT be applied to properties whose time values are specified in UTC.

normative-requirement §4.7.4 REQUIRED

The VERSION property is REQUIRED in the VCALENDAR object and MUST specify '2.0' for conformance with this specification. The PRODID property is also REQUIRED and MUST contain the globally unique identifier string for the product that created the iCalendar object.

normative-requirement §4.1 MUST

When parsing a content line, folded lines MUST first be unfolded by removing the CRLF and the immediately following single linear white space character. Unfolding restores the logical single-line representation before value parsing.

protocol-element §4.8.4.1

The ATTENDEE property conveys the CAL-ADDRESS of a calendar user invited to a component. It supports CN, CUTYPE, DELEGATED-FROM, DELEGATED-TO, DIR, LANGUAGE, MEMBER, PARTSTAT, ROLE, RSVP, and SENT-BY parameters. Internet email addresses MUST be MAILTO URIs.

protocol-element §3.1

The iCalendar MIME content type is 'text/calendar'. Optional MIME parameters include charset, method, component, and optinfo. The file extension '.ics' designates a calendar file; '.ifb' designates a free/busy time file.

registry

protocol-element §4.4

The iCalendar object is a VCALENDAR wrapper delimited by BEGIN:VCALENDAR and END:VCALENDAR. It contains required calendar properties (PRODID, VERSION) and zero or more calendar components (VEVENT, VTODO, VJOURNAL, VFREEBUSY, VTIMEZONE). The CALSCALE and METHOD properties are optional.

protocol-element §4.8.4.3

The ORGANIZER property specifies the CAL-ADDRESS of the calendar user who created or is responsible for a VEVENT, VTODO, VJOURNAL, or VFREEBUSY component. It supports CN, DIR, SENT-BY, and LANGUAGE parameters.

protocol-element §4.8.4.4

The RECURRENCE-ID property identifies a specific instance of a recurring event, to-do, or journal for the purpose of modifying or deleting that instance. The RANGE parameter (THISANDPRIOR or THISANDFUTURE) extends the modification to a contiguous range of instances.

protocol-element §4.8.7.4

The SEQUENCE property defines the revision number of a calendar component, starting at 0 and incremented each time the Organizer makes a significant revision. It is used with UID and ORGANIZER to manage versioning across scheduling messages.

protocol-element §4.8.4.7

The UID property provides a globally unique identifier for a calendar component and MUST be present in VEVENT, VTODO, and VJOURNAL components. Together with SEQUENCE and ORGANIZER, it identifies all revisions of a particular calendar entity.

protocol-element §4.6.6

The VALARM component defines an alarm attached to a VEVENT or VTODO. The required ACTION property specifies the alarm type: AUDIO, DISPLAY, EMAIL, or PROCEDURE. TRIGGER (required) specifies when the alarm fires; REPEAT and DURATION together define repeating alarms.

protocol-element §4.6.1

The VEVENT component specifies a calendared event. It requires UID and DTSTAMP; supports DTSTART, DTEND or DURATION, SUMMARY, DESCRIPTION, LOCATION, ATTENDEE, ORGANIZER, RRULE, EXRULE, RDATE, EXDATE, SEQUENCE, STATUS, TRANSP, RECURRENCE-ID, and VALARM sub-components.

protocol-element §4.6.5

The VTIMEZONE component provides time zone definition data. It requires the TZID property and at least one STANDARD or DAYLIGHT sub-component, each of which must include DTSTART, TZOFFSETFROM, and TZOFFSETTO. An optional TZURL property references an externally maintained definition.

protocol-element §4.6.2

The VTODO component specifies an action item or to-do task. It requires UID and DTSTAMP and adds PERCENT-COMPLETE, COMPLETED, and DUE properties. PARTSTAT for VTODO extends the VEVENT values with COMPLETED and IN-PROCESS.

registry §7

This document registers the MIME content type 'text/calendar' with IANA and establishes a registration process (section 7) for new iCalendar object methods and new properties. New properties must be defined, posted for public comment, and submitted for approval before use in released products.

registry

security-consideration §3.5

Attachments and URI references: An iCalendar object can include URI references to programmed resources. Implementations must be aware of the network security implications of fetching or executing content at such URIs.

security

security-consideration §3.5

Procedural alarms: A VALARM of type PROCEDURE can carry an ATTACH property containing executable content. Implementations that execute such attachments are subject to virus or malicious attack. Implementers should follow electronic mail security practices when accepting and parsing iCalendar objects.

security

security-consideration §3.5

Spoofing: Only the Organizer is authorized to modify and redistribute updates to an existing VEVENT, VTODO, or VJOURNAL component. A malicious actor may construct an iCalendar object that cancels or alters a component and send it to Attendees. Only an Attendee is authorized to update their own ATTENDEE parameters and send the result to the Organizer.

security

wire-format §4.1

A content line has the ABNF form: name *(';' param) ':' value CRLF, where CRLF is US-ASCII decimal 13 followed by decimal 10. All property names, parameter names, enumerated values, and parameter values are case-insensitive; all other property values are case-sensitive.

wire-format §4.3.5

The DATE-TIME value type supports three forms: (1) floating local time — no UTC designator and no TZID; (2) UTC time — trailing 'Z' suffix (US-ASCII decimal 90); and (3) local time with time zone reference using the TZID parameter. The UTC offset form (e.g., -0800 appended directly) MUST NOT be used.

wire-format §4.3.10

The RECUR value type requires the FREQ rule part (SECONDLY, MINUTELY, HOURLY, DAILY, WEEKLY, MONTHLY, or YEARLY). UNTIL and COUNT MUST NOT both appear in the same recurrence rule. All other rule parts (INTERVAL, BYDAY, BYMONTH, BYSETPOS, WKST, etc.) are optional but MUST NOT appear more than once.