Try out our new RRULE tool for creating RRULE compatible strings.

Calendar object resources contained in calendar collections MUST NOT contain more than one type of calendar component (e.g., VEVENT, VTODO, VJOURNAL, VFREEBUSY, etc.) with the exception of VTIMEZONE components, which MUST be specified for each unique TZID parameter value specified in the iCalendar object. For instance, a calendar object resource can contain one VEVENT component and one VTIMEZONE component, but it cannot contain one VEVENT component and one VTODO component. Instead, the VEVENT and VTODO components would have to be stored in separate calendar object resources in the same collection.

Calendar object resources contained in calendar collections MUST NOT specify the iCalendar METHOD property.

The UID property value of the calendar components contained in a calendar object resource MUST be unique in the scope of the calendar collection in which they are stored.

Calendar components in a calendar collection that have different UID property values MUST be stored in separate calendar object resources.

Calendar components with the same UID property value, in a given calendar collection, MUST be contained in the same calendar object resource. This ensures that all components in a recurrence "set" are contained in the same calendar object resource. It is possible for a calendar object resource to just contain components that represent "overridden" instances (ones that modify the behavior of a regular instance, and thus include a RECURRENCE-ID property) without also including the "master" recurring component (the one that defines the recurrence "set" and does not contain any RECURRENCE-ID property).

For example, given the following iCalendar object:

BEGIN:VCALENDAR
PRODID:-//Example Corp.//CalDAV Client//EN
VERSION:2.0
BEGIN:VEVENT
UID:1@example.com
SUMMARY:One-off Meeting
DTSTAMP:20041210T183904Z
DTSTART:20041207T120000Z
DTEND:20041207T130000Z
END:VEVENT
BEGIN:VEVENT
UID:2@example.com
SUMMARY:Weekly Meeting
DTSTAMP:20041210T183838Z
DTSTART:20041206T120000Z
DTEND:20041206T130000Z
RRULE:FREQ=WEEKLY
END:VEVENT
BEGIN:VEVENT
UID:2@example.com
SUMMARY:Weekly Meeting
RECURRENCE-ID:20041213T120000Z
DTSTAMP:20041210T183838Z
DTSTART:20041213T130000Z
DTEND:20041213T140000Z
END:VEVENT
END:VCALENDAR

The VEVENT component with the UID value "1@example.com" would be stored in its own calendar object resource. The two VEVENT components with the UID value "2@example.com", which represent a recurring event where one recurrence instance has been overridden, would be stored in the same calendar object resource.

This document was automatically converted to XHTML using an RFC to HTML converter with the original text document at the Internet Engineering Task Force web site at ietf.org .  The original text document should be referred to if there are any errors or discrepancies found in this document.

Need to test your iCalendar feeds?

The iCalendar Validator provides developers and testers a method to validate their iCalendar feeds, which can take data from either a URL, file or text snippet and compare it against the RFC 5545 specification.  We believe we have one of the best iCalendar validation tools available on the internet. More information about the validator can be found here.