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

CalDAV Access (RFC 4791)

Abstract

This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the "calendar-access" feature of CalDAV.

Author

C. Daboo, Apple; B. Desruisseaux, Oracle; L. Dusseault, Commercenet; March 2007

5.3.2. Creating Calendar Object Resources

Clients populate calendar collections with calendar object resources. The URL for each calendar object resource is entirely arbitrary and does not need to bear a specific relationship to the calendar object resource's iCalendar properties or other metadata. New calendar object resources MUST be created with a PUT request targeted at an unmapped URI. A PUT request targeted at a mapped URI updates an existing calendar object resource.

When servers create new resources, it's not hard for the server to choose an unmapped URI. It's slightly tougher for clients, because a client might not want to examine all resources in the collection and might not want to lock the entire collection to ensure that a new resource isn't created with a name collision. However, there is an HTTP feature to mitigate this. If the client intends to create a new non-collection resource, such as a new VEVENT, the client SHOULD use the HTTP request header "If-None-Match: *" on the PUT request. The Request-URI on the PUT request MUST include the target collection, where the resource is to be created, plus the name of the resource in the last path segment. The "If-None-Match: *" request header ensures that the client will not inadvertently overwrite an existing resource if the last path segment turned out to already be used.

>> Request <<

PUT /home/lisa/calendars/events/qwue23489.ics HTTP/1.1 If-None-Match: * Host: cal.example.com Content-Type: text/calendar Content-Length: xxxx

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VEVENT
UID:20010712T182145Z-123401@example.com
DTSTAMP:20060712T182145Z
DTSTART:20060714T170000Z
DTEND:20060715T040000Z
SUMMARY:Bastille Day Party
END:VEVENT
END:VCALENDAR

>> Response <<

HTTP/1.1 201 Created Content-Length: 0 Date: Sat, 11 Nov 2006 09:32:12 GMT ETag: "123456789-000-111"

The request to change an existing event is the same, but with a specific ETag in the "If-Match" header, rather than the "If-None- Match" header.

As indicated in Section 3.10 of [RFC2445], the URL of calendar object resources containing (an arbitrary set of) calendaring and scheduling information may be suffixed by ".ics", and the URL of calendar object resources containing free or busy time information may be suffixed by ".ifb".

10. Internationalization Considerations

CalDAV allows internationalized strings to be stored and retrieved for the description of calendar collections (see Section 5.2.1).

The CALDAV

calendar-query REPORT (Section 7.8) includes a text searching option controlled by the CALDAV:text-match element, and details of character handling are covered in the description of that element (see Section 9.7.5).

5.3.2.1. Additional Preconditions for PUT, COPY, and MOVE

This specification creates additional Preconditions for PUT, COPY, and MOVE methods. These preconditions apply when a PUT operation of a calendar object resource into a calendar collection occurs, or when a COPY or MOVE operation of a calendar object resource into a calendar collection occurs, or when a COPY or MOVE operation occurs on a calendar collection.

The new preconditions are:

(CALDAV

supported-calendar-data) PUT request, or targeted by a COPY or MOVE request, MUST be a supported media type (i.e., iCalendar) for calendar object resources;

(CALDAV

valid-calendar-data) request, or targeted by a COPY or MOVE request, MUST be valid data for the media type being specified (i.e., MUST contain valid iCalendar data);

(CALDAV

valid-calendar-object-resource) the PUT request, or targeted by a COPY or MOVE request, MUST obey all restrictions specified in Section 4.1 (e.g., calendar object resources MUST NOT contain more than one type of calendar component, calendar object resources MUST NOT specify the iCalendar METHOD property, etc.);

(CALDAV

supported-calendar-component) the PUT request, or targeted by a COPY or MOVE request, MUST contain a type of calendar component that is supported in the targeted calendar collection;

(CALDAV

no-uid-conflict) request, or targeted by a COPY or MOVE request, MUST NOT specify an iCalendar UID property value already in use in the targeted calendar collection or overwrite an existing calendar object resource with one that has a different UID property value. Servers SHOULD report the URL of the resource that is already making use of the same UID property value in the DAV:href element;

(CALDAV

calendar-collection-location-ok) request, when the Request-URI is a calendar collection, the Destination-URI MUST identify a location where a calendar collection can be created;

(CALDAV

max-resource-size) request, or targeted by a COPY or MOVE request, MUST have an octet size less than or equal to the value of the CALDAV:max-resource- size property value (Section 5.2.5) on the calendar collection where the resource will be stored;

(CALDAV

min-date-time) or targeted by a COPY or MOVE request, MUST have all of its iCalendar DATE or DATE-TIME property values (for each recurring instance) greater than or equal to the value of the CALDAV:min- date-time property value (Section 5.2.6) on the calendar collection where the resource will be stored;

(CALDAV

max-date-time) or targeted by a COPY or MOVE request, MUST have all of its iCalendar DATE or DATE-TIME property values (for each recurring instance) less than the value of the CALDAV:max-date-time property value (Section 5.2.7) on the calendar collection where the resource will be stored;

(CALDAV

max-instances) or targeted by a COPY or MOVE request, MUST generate a number of recurring instances less than or equal to the value of the CALDAV: max-instances property value (Section 5.2.8) on the calendar collection where the resource will be stored;

(CALDAV

max-attendees-per-instance) PUT request, or targeted by a COPY or MOVE request, MUST have a number of ATTENDEE properties on any one instance less than or equal to the value of the CALDAV:max-attendees-per-instance property value (Section 5.2.9) on the calendar collection where the resource will be stored;

5.3.3. Non-Standard Components, Properties, and Parameters

iCalendar provides a "standard mechanism for doing non-standard things". This extension support allows implementers to make use of non-standard components, properties, and parameters whose names are prefixed with the text "X-".

Servers MUST support the use of non-standard components, properties, and parameters in calendar object resources stored via the PUT method.

Servers may need to enforce rules for their own "private" components, properties, or parameters, so servers MAY reject any attempt by the client to change those or use values for those outside of any restrictions the server may have. Servers SHOULD ensure that any "private" components, properties, or parameters it uses follow the convention of including a vendor id in the "X-" name, as described in Section 4.2 of [RFC2445], e.g., "X-ABC-PRIVATE".

Page 13 of 29

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.