RFC 4791
Calendaring Extensions to WebDAV (CalDAV)
Pages: 107
Proposed Standard
→ Errata
Updated by: 5689 6638 6764 7809 7953 8996
Proposed Standard
→ Errata
Updated by: 5689 6638 6764 7809 7953 8996
Part 5 of 5 – Pages 77 to 107
9. XML Element Definitions
9.1. CALDAV:calendar XML Element
Name: calendar Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specifies the resource type of a calendar collection. Description: See Section 4.2. Definition: <!ELEMENT calendar EMPTY>9.2. CALDAV:mkcalendar XML Element
Name: mkcalendar Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specifies a request that includes the WebDAV property values to be set for a calendar collection resource when it is created. Description: See Section 5.3.1. Definition: <!ELEMENT mkcalendar (DAV:set)>
9.3. CALDAV:mkcalendar-response XML Element
Name: mkcalendar-response Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specifies a response body for a successful MKCALENDAR request. Description: See Section 5.3.1. Definition: <!ELEMENT mkcalendar-response ANY>9.4. CALDAV:supported-collation XML Element
Name: supported-collation Namespace: urn:ietf:params:xml:ns:caldav Purpose: Identifies a single collation via its collation identifier, as defined by [RFC4790]. Description: The CALDAV:supported-collation contains the text of a collation identifier, as described in Section 7.5.1. Definition: <!ELEMENT supported-collation (#PCDATA)> PCDATA value: collation identifier9.5. CALDAV:calendar-query XML Element
Name: calendar-query Namespace: urn:ietf:params:xml:ns:caldav Purpose: Defines a report for querying calendar object resources. Description: See Section 7.8. Definition: <!ELEMENT calendar-query ((DAV:allprop | DAV:propname | DAV:prop)?, filter, timezone?)>
9.6. CALDAV:calendar-data XML Element
Name: calendar-data Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specified one of the following: 1. A supported media type for calendar object resources when nested in the CALDAV:supported-calendar-data property; 2. The parts of a calendar object resource should be returned by a calendaring report; 3. The content of a calendar object resource in a response to a calendaring report. Description: When nested in the CALDAV:supported-calendar-data property, the CALDAV:calendar-data XML element specifies a media type supported by the CalDAV server for calendar object resources. When used in a calendaring REPORT request, the CALDAV:calendar- data XML element specifies which parts of calendar object resources need to be returned in the response. If the CALDAV: calendar-data XML element doesn't contain any CALDAV:comp element, calendar object resources will be returned in their entirety. Finally, when used in a calendaring REPORT response, the CALDAV: calendar-data XML element specifies the content of a calendar object resource. Given that XML parsers normalize the two- character sequence CRLF (US-ASCII decimal 13 and US-ASCII decimal 10) to a single LF character (US-ASCII decimal 10), the CR character (US-ASCII decimal 13) MAY be omitted in calendar object resources specified in the CALDAV:calendar-data XML element. Furthermore, calendar object resources specified in the CALDAV: calendar-data XML element MAY be invalid per their media type specification if the CALDAV:calendar-data XML element part of the calendaring REPORT request did not specify required properties (e.g., UID, DTSTAMP, etc.), or specified a CALDAV:prop XML element with the "novalue" attribute set to "yes". Note: The CALDAV:calendar-data XML element is specified in requests and responses inside the DAV:prop XML element as if it were a WebDAV property. However, the CALDAV:calendar-data XML element is not a WebDAV property and, as such, is not returned in PROPFIND responses, nor used in PROPPATCH requests.
Note: The iCalendar data embedded within the CALDAV:calendar-data
XML element MUST follow the standard XML character data encoding
rules, including use of <, >, & etc. entity encoding or
the use of a <![CDATA[ ... ]]> construct. In the later case, the
iCalendar data cannot contain the character sequence "]]>", which
is the end delimiter for the CDATA section.
Definition:
<!ELEMENT calendar-data EMPTY>
when nested in the CALDAV:supported-calendar-data property
to specify a supported media type for calendar object
resources;
<!ELEMENT calendar-data (comp?,
(expand | limit-recurrence-set)?,
limit-freebusy-set?)>
when nested in the DAV:prop XML element in a calendaring
REPORT request to specify which parts of calendar object
resources should be returned in the response;
<!ELEMENT calendar-data (#PCDATA)>
PCDATA value: iCalendar object
when nested in the DAV:prop XML element in a calendaring
REPORT response to specify the content of a returned
calendar object resource.
<!ATTLIST calendar-data content-type CDATA "text/calendar"
version CDATA "2.0">
content-type value: a MIME media type
version value: a version string
attributes can be used on all three variants of the
CALDAV:calendar-data XML element.
9.6.1. CALDAV:comp XML Element
Name: comp
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Defines which component types to return.
Description: The name value is a calendar component name (e.g.,
VEVENT).
Definition:
<!ELEMENT comp ((allprop | prop*), (allcomp | comp*))>
<!ATTLIST comp name CDATA #REQUIRED>
name value: a calendar component name
Note: The CALDAV:prop and CALDAV:allprop elements have the same name
as the DAV:prop and DAV:allprop elements defined in [RFC2518].
However, the CALDAV:prop and CALDAV:allprop elements are defined
in the "urn:ietf:params:xml:ns:caldav" namespace instead of the
"DAV:" namespace.
9.6.2. CALDAV:allcomp XML Element
Name: allcomp
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Specifies that all components shall be returned.
Description: The CALDAV:allcomp XML element can be used when the
client wants all types of components returned by a calendaring
REPORT request.
Definition:
<!ELEMENT allcomp EMPTY>
9.6.3. CALDAV:allprop XML Element
Name: allprop
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Specifies that all properties shall be returned.
Description: The CALDAV:allprop XML element can be used when the
client wants all properties of components returned by a
calendaring REPORT request.
Definition:
<!ELEMENT allprop EMPTY>
Note: The CALDAV:allprop element has the same name as the DAV:
allprop element defined in [RFC2518]. However, the CALDAV:allprop
element is defined in the "urn:ietf:params:xml:ns:caldav"
namespace instead of the "DAV:" namespace.
9.6.4. CALDAV:prop XML Element
Name: prop
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Defines which properties to return in the response.
Description: The "name" attribute specifies the name of the calendar
property to return (e.g., ATTENDEE). The "novalue" attribute can
be used by clients to request that the actual value of the
property not be returned (if the "novalue" attribute is set to
"yes"). In that case, the server will return just the iCalendar
property name and any iCalendar parameters and a trailing ":"
without the subsequent value data.
Definition:
<!ELEMENT prop EMPTY>
<!ATTLIST prop name CDATA #REQUIRED
novalue (yes | no) "no">
name value: a calendar property name
novalue value: "yes" or "no"
Note: The CALDAV:prop element has the same name as the DAV:prop
element defined in [RFC2518]. However, the CALDAV:prop element is
defined in the "urn:ietf:params:xml:ns:caldav" namespace instead
of the "DAV:" namespace.
9.6.5. CALDAV:expand XML Element
Name: expand
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Forces the server to expand recurring components into
individual recurrence instances.
Description: The CALDAV:expand XML element specifies that for a
given calendaring REPORT request, the server MUST expand the
recurrence set into calendar components that define exactly one
recurrence instance, and MUST return only those whose scheduled
time intersect a specified time range.
The "start" attribute specifies the inclusive start of the time
range, and the "end" attribute specifies the non-inclusive end of
the time range. Both attributes are specified as date with UTC
time value. The value of the "end" attribute MUST be greater than
the value of the "start" attribute.
The server MUST use the same logic as defined for CALDAV:time-
range to determine if a recurrence instance intersects the
specified time range.
Recurring components, other than the initial instance, MUST
include a RECURRENCE-ID property indicating which instance they
refer to.
The returned calendar components MUST NOT use recurrence
properties (i.e., EXDATE, EXRULE, RDATE, and RRULE) and MUST NOT
have reference to or include VTIMEZONE components. Date and local
time with reference to time zone information MUST be converted
into date with UTC time.
Definition:
<!ELEMENT expand EMPTY>
<!ATTLIST expand start CDATA #REQUIRED
end CDATA #REQUIRED>
start value: an iCalendar "date with UTC time"
end value: an iCalendar "date with UTC time"
9.6.6. CALDAV:limit-recurrence-set XML Element
Name: limit-recurrence-set
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Specifies a time range to limit the set of "overridden
components" returned by the server.
Description: The CALDAV:limit-recurrence-set XML element specifies
that for a given calendaring REPORT request, the server MUST
return, in addition to the "master component", only the
"overridden components" that impact a specified time range. An
overridden component impacts a time range if its current start and
end times overlap the time range, or if the original start and end
times -- the ones that would have been used if the instance were
not overridden -- overlap the time range.
The "start" attribute specifies the inclusive start of the time
range, and the "end" attribute specifies the non-inclusive end of
the time range. Both attributes are specified as date with UTC
time value. The value of the "end" attribute MUST be greater than
the value of the "start" attribute.
The server MUST use the same logic as defined for CALDAV:time-
range to determine if the current or original scheduled time of an
"overridden" recurrence instance intersects the specified time
range.
Overridden components that have a RANGE parameter on their
RECURRENCE-ID property may specify one or more instances in the
recurrence set, and some of those instances may fall within the
specified time range or may have originally fallen within the
specified time range prior to being overridden. If that is the
case, the overridden component MUST be included in the results, as
it has a direct impact on the interpretation of instances within
the specified time range.
Definition:
<!ELEMENT limit-recurrence-set EMPTY>
<!ATTLIST limit-recurrence-set start CDATA #REQUIRED
end CDATA #REQUIRED>
start value: an iCalendar "date with UTC time"
end value: an iCalendar "date with UTC time"
9.6.7. CALDAV:limit-freebusy-set XML Element
Name: limit-freebusy-set
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Specifies a time range to limit the set of FREEBUSY values
returned by the server.
Description: The CALDAV:limit-freebusy-set XML element specifies
that for a given calendaring REPORT request, the server MUST only
return the FREEBUSY property values of a VFREEBUSY component that
intersects a specified time range.
The "start" attribute specifies the inclusive start of the time
range, and the "end" attribute specifies the non-inclusive end of
the time range. Both attributes are specified as "date with UTC
time" value. The value of the "end" attribute MUST be greater
than the value of the "start" attribute.
The server MUST use the same logic as defined for CALDAV:time-
range to determine if a FREEBUSY property value intersects the
specified time range.
Definition:
<!ELEMENT limit-freebusy-set EMPTY>
<!ATTLIST limit-freebusy-set start CDATA #REQUIRED
end CDATA #REQUIRED>
start value: an iCalendar "date with UTC time"
end value: an iCalendar "date with UTC time"
9.7. CALDAV:filter XML Element
Name: filter
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Specifies a filter to limit the set of calendar components
returned by the server.
Description: The CALDAV:filter XML element specifies the search
filter used to limit the calendar components returned by a
calendaring REPORT request.
Definition:
<!ELEMENT filter (comp-filter)>
9.7.1. CALDAV:comp-filter XML Element
Name: comp-filter
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Specifies search criteria on calendar components.
Description: The CALDAV:comp-filter XML element specifies a query
targeted at the calendar object (i.e., VCALENDAR) or at a specific
calendar component type (e.g., VEVENT). The scope of the
CALDAV:comp-filter XML element is the calendar object when used as
a child of the CALDAV:filter XML element. The scope of the
CALDAV:comp-filter XML element is the enclosing calendar component
when used as a child of another CALDAV:comp-filter XML element. A
CALDAV:comp-filter is said to match if:
* The CALDAV:comp-filter XML element is empty and the calendar
object or calendar component type specified by the "name"
attribute exists in the current scope;
or:
* The CALDAV:comp-filter XML element contains a CALDAV:is-not-
defined XML element and the calendar object or calendar
component type specified by the "name" attribute does not exist
in the current scope;
or:
* The CALDAV:comp-filter XML element contains a CALDAV:time-range
XML element and at least one recurrence instance in the
targeted calendar component is scheduled to overlap the
specified time range, and all specified CALDAV:prop-filter and
CALDAV:comp-filter child XML elements also match the targeted
calendar component;
or:
* The CALDAV:comp-filter XML element only contains CALDAV:prop-
filter and CALDAV:comp-filter child XML elements that all match
the targeted calendar component.
Definition:
<!ELEMENT comp-filter (is-not-defined | (time-range?,
prop-filter*, comp-filter*))>
<!ATTLIST comp-filter name CDATA #REQUIRED>
name value: a calendar object or calendar component
type (e.g., VEVENT)
9.7.2. CALDAV:prop-filter XML Element
Name: prop-filter
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Specifies search criteria on calendar properties.
Description: The CALDAV:prop-filter XML element specifies a query
targeted at a specific calendar property (e.g., CATEGORIES) in the
scope of the enclosing calendar component. A calendar property is
said to match a CALDAV:prop-filter if:
* The CALDAV:prop-filter XML element is empty and a property of
the type specified by the "name" attribute exists in the
enclosing calendar component;
or:
* The CALDAV:prop-filter XML element contains a CALDAV:is-not-
defined XML element and no property of the type specified by
the "name" attribute exists in the enclosing calendar
component;
or:
* The CALDAV:prop-filter XML element contains a CALDAV:time-range
XML element and the property value overlaps the specified time
range, and all specified CALDAV:param-filter child XML elements
also match the targeted property;
or:
* The CALDAV:prop-filter XML element contains a CALDAV:text-match
XML element and the property value matches it, and all
specified CALDAV:param-filter child XML elements also match the
targeted property;
Definition:
<!ELEMENT prop-filter (is-not-defined |
((time-range | text-match)?,
param-filter*))>
<!ATTLIST prop-filter name CDATA #REQUIRED>
name value: a calendar property name (e.g., ATTENDEE)
9.7.3. CALDAV:param-filter XML Element
Name: param-filter
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Limits the search to specific parameter values.
Description: The CALDAV:param-filter XML element specifies a query
targeted at a specific calendar property parameter (e.g.,
PARTSTAT) in the scope of the calendar property on which it is
defined. A calendar property parameter is said to match a CALDAV:
param-filter if:
* The CALDAV:param-filter XML element is empty and a parameter of
the type specified by the "name" attribute exists on the
calendar property being examined;
or:
* The CALDAV:param-filter XML element contains a CALDAV:is-not-
defined XML element and no parameter of the type specified by
the "name" attribute exists on the calendar property being
examined;
Definition:
<!ELEMENT param-filter (is-not-defined | text-match?)>
<!ATTLIST param-filter name CDATA #REQUIRED>
name value: a property parameter name (e.g., PARTSTAT)
9.7.4. CALDAV:is-not-defined XML Element
Name: is-not-defined
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Specifies that a match should occur if the enclosing
component, property, or parameter does not exist.
Description: The CALDAV:is-not-defined XML element specifies that a
match occurs if the enclosing component, property, or parameter
value specified in a calendaring REPORT request does not exist in
the calendar data being tested.
Definition:
<!ELEMENT is-not-defined EMPTY>
9.7.5. CALDAV:text-match XML Element
Name: text-match
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Specifies a substring match on a property or parameter
value.
Description: The CALDAV:text-match XML element specifies text used
for a substring match against the property or parameter value
specified in a calendaring REPORT request.
The "collation" attribute is used to select the collation that the
server MUST use for character string matching. In the absence of
this attribute, the server MUST use the "i;ascii-casemap"
collation.
The "negate-condition" attribute is used to indicate that this
test returns a match if the text matches when the attribute value
is set to "no", or return a match if the text does not match, if
the attribute value is set to "yes". For example, this can be
used to match components with a STATUS property not set to
CANCELLED.
Definition:
<!ELEMENT text-match (#PCDATA)>
PCDATA value: string
<!ATTLIST text-match collation CDATA "i;ascii-casemap"
negate-condition (yes | no) "no">
9.8. CALDAV:timezone XML Element
Name: timezone
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Specifies the time zone component to use when determining
the results of a report.
Description: The CALDAV:timezone XML element specifies that for a
given calendaring REPORT request, the server MUST rely on the
specified VTIMEZONE component instead of the CALDAV:calendar-
timezone property of the calendar collection, in which the
calendar object resource is contained to resolve "date" values and
"date with local time" values (i.e., floating time) to "date with
UTC time" values. The server will require this information to
determine if a calendar component scheduled with "date" values or
"date with local time" values intersects a CALDAV:time-range
specified in a CALDAV:calendar-query REPORT.
Note: The iCalendar data embedded within the CALDAV:timezone XML
element MUST follow the standard XML character data encoding
rules, including use of <, >, & etc. entity encoding or
the use of a <![CDATA[ ... ]]> construct. In the later case, the
iCalendar data cannot contain the character sequence "]]>", which
is the end delimiter for the CDATA section.
Definition:
<!ELEMENT timezone (#PCDATA)>
PCDATA value: an iCalendar object with exactly one VTIMEZONE
9.9. CALDAV:time-range XML Element
Name: time-range
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Specifies a time range to limit the set of calendar
components returned by the server.
Description: The CALDAV:time-range XML element specifies that for a
given calendaring REPORT request, the server MUST only return the
calendar object resources that, depending on the context, have a
component or property whose value intersects a specified time
range.
The "start" attribute specifies the inclusive start of the time
range, and the "end" attribute specifies the non-inclusive end of
the time range. Both attributes MUST be specified as "date with
UTC time" value. Time ranges open at one end can be specified by
including only one attribute; however, at least one attribute MUST
always be present in the CALDAV:time-range element. If either the
"start" or "end" attribute is not specified in the CALDAV:time-
range XML element, assume "-infinity" and "+infinity" as their
value, respectively. If both "start" and "end" are present, the
value of the "end" attribute MUST be greater than the value of the
"start" attribute.
Time range tests MUST consider every recurrence instance when
testing the time range condition; if any one instance matches,
then the test returns true. Testing recurrence instances requires
the server to infer an effective value for DTSTART, DTEND,
DURATION, and DUE properties for an instance based on the
recurrence patterns and any overrides.
A VEVENT component overlaps a given time range if the condition
for the corresponding component state specified in the table below
is satisfied. Note that, as specified in [RFC2445], the DTSTART
property is REQUIRED in the VEVENT component. The conditions
depend on the presence of the DTEND and DURATION properties in the
VEVENT component. Furthermore, the value of the DTEND property
MUST be later in time than the value of the DTSTART property. The
duration of a VEVENT component with no DTEND and DURATION
properties is 1 day (+P1D) when the DTSTART is a DATE value, and 0
seconds when the DTSTART is a DATE-TIME value.
+---------------------------------------------------------------+
| VEVENT has the DTEND property? |
| +-----------------------------------------------------------+
| | VEVENT has the DURATION property? |
| | +-------------------------------------------------------+
| | | DURATION property value is greater than 0 seconds? |
| | | +---------------------------------------------------+
| | | | DTSTART property is a DATE-TIME value? |
| | | | +-----------------------------------------------+
| | | | | Condition to evaluate |
+---+---+---+---+-----------------------------------------------+
| Y | N | N | * | (start < DTEND AND end > DTSTART) |
+---+---+---+---+-----------------------------------------------+
| N | Y | Y | * | (start < DTSTART+DURATION AND end > DTSTART) |
| | +---+---+-----------------------------------------------+
| | | N | * | (start <= DTSTART AND end > DTSTART) |
+---+---+---+---+-----------------------------------------------+
| N | N | N | Y | (start <= DTSTART AND end > DTSTART) |
+---+---+---+---+-----------------------------------------------+
| N | N | N | N | (start < DTSTART+P1D AND end > DTSTART) |
+---+---+---+---+-----------------------------------------------+
A VTODO component is said to overlap a given time range if the
condition for the corresponding component state specified in the
table below is satisfied. The conditions depend on the presence
of the DTSTART, DURATION, DUE, COMPLETED, and CREATED properties
in the VTODO component. Note that, as specified in [RFC2445], the
DUE value MUST be a DATE-TIME value equal to or after the DTSTART
value if specified.
+-------------------------------------------------------------------+
| VTODO has the DTSTART property? |
| +---------------------------------------------------------------+
| | VTODO has the DURATION property? |
| | +-----------------------------------------------------------+
| | | VTODO has the DUE property? |
| | | +-------------------------------------------------------+
| | | | VTODO has the COMPLETED property? |
| | | | +---------------------------------------------------+
| | | | | VTODO has the CREATED property? |
| | | | | +-----------------------------------------------+
| | | | | | Condition to evaluate |
+---+---+---+---+---+-----------------------------------------------+
| Y | Y | N | * | * | (start <= DTSTART+DURATION) AND |
| | | | | | ((end > DTSTART) OR |
| | | | | | (end >= DTSTART+DURATION)) |
+---+---+---+---+---+-----------------------------------------------+
| Y | N | Y | * | * | ((start < DUE) OR (start <= DTSTART)) |
| | | | | | AND |
| | | | | | ((end > DTSTART) OR (end >= DUE)) |
+---+---+---+---+---+-----------------------------------------------+
| Y | N | N | * | * | (start <= DTSTART) AND (end > DTSTART) |
+---+---+---+---+---+-----------------------------------------------+
| N | N | Y | * | * | (start < DUE) AND (end >= DUE) |
+---+---+---+---+---+-----------------------------------------------+
| N | N | N | Y | Y | ((start <= CREATED) OR (start <= COMPLETED))|
| | | | | | AND |
| | | | | | ((end >= CREATED) OR (end >= COMPLETED))|
+---+---+---+---+---+-----------------------------------------------+
| N | N | N | Y | N | (start <= COMPLETED) AND (end >= COMPLETED) |
+---+---+---+---+---+-----------------------------------------------+
| N | N | N | N | Y | (end > CREATED) |
+---+---+---+---+---+-----------------------------------------------+
| N | N | N | N | N | TRUE |
+---+---+---+---+---+-----------------------------------------------+
A VJOURNAL component overlaps a given time range if the condition
for the corresponding component state specified in the table below
is satisfied. The conditions depend on the presence of the
DTSTART property in the VJOURNAL component and on whether the
DTSTART is a DATE-TIME or DATE value. The effective "duration" of
a VJOURNAL component is 1 day (+P1D) when the DTSTART is a DATE
value, and 0 seconds when the DTSTART is a DATE-TIME value.
+----------------------------------------------------+
| VJOURNAL has the DTSTART property? |
| +------------------------------------------------+
| | DTSTART property is a DATE-TIME value? |
| | +--------------------------------------------+
| | | Condition to evaluate |
+---+---+--------------------------------------------+
| Y | Y | (start <= DTSTART) AND (end > DTSTART) |
+---+---+--------------------------------------------+
| Y | N | (start < DTSTART+P1D) AND (end > DTSTART) |
+---+---+--------------------------------------------+
| N | * | FALSE |
+---+---+--------------------------------------------+
A VFREEBUSY component overlaps a given time range if the condition
for the corresponding component state specified in the table below
is satisfied. The conditions depend on the presence in the
VFREEBUSY component of the DTSTART and DTEND properties, and any
FREEBUSY properties in the absence of DTSTART and DTEND. Any
DURATION property is ignored, as it has a special meaning when
used in a VFREEBUSY component.
When only FREEBUSY properties are used, each period in each
FREEBUSY property is compared against the time range, irrespective
of the type of free busy information (free, busy, busy-tentative,
busy-unavailable) represented by the property.
+------------------------------------------------------+
| VFREEBUSY has both the DTSTART and DTEND properties? |
| +--------------------------------------------------+
| | VFREEBUSY has the FREEBUSY property? |
| | +----------------------------------------------+
| | | Condition to evaluate |
+---+---+----------------------------------------------+
| Y | * | (start <= DTEND) AND (end > DTSTART) |
+---+---+----------------------------------------------+
| N | Y | (start < freebusy-period-end) AND |
| | | (end > freebusy-period-start) |
+---+---+----------------------------------------------+
| N | N | FALSE |
+---+---+----------------------------------------------+
A VALARM component is said to overlap a given time range if the
following condition holds:
(start <= trigger-time) AND (end > trigger-time)
A VALARM component can be defined such that it triggers repeatedly.
Such a VALARM component is said to overlap a given time range if at
least one of its triggers overlaps the time range.
The calendar properties COMPLETED, CREATED, DTEND, DTSTAMP,
DTSTART, DUE, and LAST-MODIFIED overlap a given time range if the
following condition holds:
(start <= date-time) AND (end > date-time)
Note that if DTEND is not present in a VEVENT, but DURATION is, then
the test should instead operate on the 'effective' DTEND, i.e.,
DTSTART+DURATION. Similarly, if DUE is not present in a VTODO, but
DTSTART and DURATION are, then the test should instead operate on the
'effective' DUE, i.e., DTSTART+DURATION.
The semantic of CALDAV:time-range is not defined for any other
calendar components and properties.
Definition:
<!ELEMENT time-range EMPTY>
<!ATTLIST time-range start CDATA #IMPLIED
end CDATA #IMPLIED>
start value: an iCalendar "date with UTC time"
end value: an iCalendar "date with UTC time"
9.10. CALDAV:calendar-multiget XML Element
Name: calendar-multiget
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: CalDAV report used to retrieve specific calendar object
resources.
Description: See Section 7.9.
Definition:
<!ELEMENT calendar-multiget ((DAV:allprop |
DAV:propname |
DAV:prop)?, DAV:href+)>
9.11. CALDAV:free-busy-query XML Element
Name: free-busy-query Namespace: urn:ietf:params:xml:ns:caldav Purpose: CalDAV report used to generate a VFREEBUSY to determine busy time over a specific time range. Description: See Section 7.10. Definition: <!ELEMENT free-busy-query (time-range)>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).11. Security Considerations
HTTP protocol transactions are sent in the clear over the network unless protection from snooping is negotiated. This can be accomplished by use of TLS, as defined in [RFC2818]. In particular, HTTP Basic authentication MUST NOT be used unless TLS is in effect. Servers MUST take adequate precautions to ensure that malicious clients cannot consume excessive server resources (CPU, memory, disk, etc.) through carefully crafted reports. For example, a client could upload an event with a recurrence rule that specifies a recurring event occurring every second for the next 100 years, which would result in approximately 3 x 10^9 instances! A report that asks for recurrences to be expanded over that range would likely constitute a denial-of-service attack on the server. When creating new resources (including calendar collections), clients MUST ensure that the resource name (the last path segment of the resource URI) assigned to the new resource does not expose any data from within the iCalendar resource itself or information about the nature of a calendar collection. This is required to ensure that the presence of a specific iCalendar component or nature of components in a collection cannot be inferred based on the name of a resource.
When rolling up free-busy information, more information about a user's events is exposed if busy periods overlap or are adjacent (this tells the client requesting the free-busy information that the calendar owner has at least two events, rather than knowing only that the calendar owner has one or more events during the busy period). Thus, a conservative approach to calendar data privacy would have servers always coalesce such busy periods when they are the same type. Procedure alarms are a known security risk for either clients or servers to handle, particularly when the alarm was created by another agent. Clients and servers are not required to execute such procedure alarms. Security considerations described in iCalendar [RFC2445] and iTIP [RFC2446] are also applicable to CalDAV. Beyond these, CalDAV does not raise any security considerations that are not present in HTTP [RFC2616] and WebDAV [RFC2518], [RFC3253], [RFC3744].12. IANA Considerations
This document uses one new URN to identify a new XML namespace. The URN conforms to a registry mechanism described in [RFC3688].12.1. Namespace Registration
Registration request for the CalDAV namespace: URI: urn:ietf:params:xml:ns:caldav Registrant Contact: See the "Authors' Addresses" section of this document. XML: None. Namespace URIs do not represent an XML specification.13. Acknowledgements
The authors would like to thank the following individuals for contributing their ideas and support for writing this specification: Michael Arick, Mario Bonin, Chris Bryant, Scott Carr, Andre Courtemanche, Mike Douglass, Ted Hardie, Marten den Haring, Jeffrey Harris, Sam Hartman, Helge Hess, Jeff McCullough, Alexey Melnikov, Dan Mosedale, Brian Moseley, Francois Perrault, Kervin L. Pierre, Julian F. Reschke, Wilfredo Sanchez Vega, Mike Shaver, Jari Urpalainen, Simon Vaillancourt, and Jim Whitehead.
The authors would also like to thank the Calendaring and Scheduling Consortium for advice with this specification, and for organizing interoperability testing events to help refine it.14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2445] Dawson, F. and Stenerson, D., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998. [RFC2446] Silverberg, S., Mansour, S., Dawson, F., and R. Hopson, "iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries", RFC 2446, November 1998. [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners- Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. Whitehead, "Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", RFC 3253, March 2002. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, May 2004. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, March 2007. [W3C.REC-xml-20060816] Paoli, J., Maler, E., Yergeau, F., Sperberg- McQueen, C., and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", World Wide Web Consortium Recommendation REC-xml- 20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-20060816>.14.2. Informative References
[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998. [RFC2739] Small, T., Hennessy, D., and F. Dawson, "Calendar Attributes for vCard and LDAP", RFC 2739, January 2000. [RFC4331] Korver, B. and L. Dusseault, "Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections", RFC 4331, February 2006. [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006. [rfc2518bis] Dusseault, L., "HTTP Extensions for Distributed Authoring - WebDAV", Work in Progress, December 2006.
Appendix A. CalDAV Method Privilege Table (Normative)
The following table extends the WebDAV Method Privilege Table specified in Appendix B of [RFC3744]. +------------+------------------------------------------------------+ | METHOD | PRIVILEGES | +------------+------------------------------------------------------+ | MKCALENDAR | DAV:bind | | REPORT | DAV:read or CALDAV:read-free-busy (on all referenced | | | resources) | +------------+------------------------------------------------------+Appendix B. Calendar Collections Used in the Examples
This appendix shows the calendar object resources contained in the calendar collection queried in the examples throughout this document. The content of the calendar collection is being shown as if it were returned by a CALDAV:calendar-query REPORT request designed to return all the calendar data in the collection: >> Request << REPORT /bernard/work/ HTTP/1.1 Host: cal.example.com Depth: 1 Content-Type: application/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <C:calendar-query xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"> <D:prop> <D:getetag/> <C:calendar-data/> </D:prop> <C:filter> <C:comp-filter name="VCALENDAR"/> </C:filter> </C:calendar-query> >> Response << HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:response>
<D:href>http://cal.example.com/bernard/work/abcd1.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>"fffff-abcd1"</D:getetag>
<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VTIMEZONE
LAST-MODIFIED:20040110T032845Z
TZID:US/Eastern
BEGIN:DAYLIGHT
DTSTART:20000404T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20001026T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20060206T001102Z
DTSTART;TZID=US/Eastern:20060102T100000
DURATION:PT1H
SUMMARY:Event #1
Description:Go Steelers!
UID:74855313FA803DA593CD579A@example.com
END:VEVENT
END:VCALENDAR
</C:calendar-data>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>"fffff-abcd2"</D:getetag>
<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VTIMEZONE
LAST-MODIFIED:20040110T032845Z
TZID:US/Eastern
BEGIN:DAYLIGHT
DTSTART:20000404T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20001026T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20060206T001121Z
DTSTART;TZID=US/Eastern:20060102T120000
DURATION:PT1H
RRULE:FREQ=DAILY;COUNT=5
SUMMARY:Event #2
UID:00959BC664CA650E933C892C@example.com
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20060206T001121Z
DTSTART;TZID=US/Eastern:20060104T140000
DURATION:PT1H
RECURRENCE-ID;TZID=US/Eastern:20060104T120000
SUMMARY:Event #2 bis
UID:00959BC664CA650E933C892C@example.com
END:VEVENT
END:VCALENDAR
</C:calendar-data>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>"fffff-abcd3"</D:getetag>
<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VTIMEZONE
LAST-MODIFIED:20040110T032845Z
TZID:US/Eastern
BEGIN:DAYLIGHT
DTSTART:20000404T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20001026T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
DTSTAMP:20060206T001220Z
DTSTART;TZID=US/Eastern:20060104T100000
DURATION:PT1H
LAST-MODIFIED:20060206T001330Z
ORGANIZER:mailto:cyrus@example.com
SEQUENCE:1
STATUS:TENTATIVE
SUMMARY:Event #3
UID:DC6C50A017428C5216A2F1CD@example.com
END:VEVENT
END:VCALENDAR
</C:calendar-data>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://cal.example.com/bernard/work/abcd4.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>"fffff-abcd4"</D:getetag>
<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VTODO
DTSTAMP:20060205T235335Z
DUE;VALUE=DATE:20060104
STATUS:NEEDS-ACTION
SUMMARY:Task #1
UID:DDDEEB7915FA61233B861457@example.com
BEGIN:VALARM
ACTION:AUDIO
TRIGGER;RELATED=START:-PT10M
END:VALARM
END:VTODO
END:VCALENDAR
</C:calendar-data>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://cal.example.com/bernard/work/abcd5.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>"fffff-abcd5"</D:getetag>
<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VTODO
DTSTAMP:20060205T235300Z
DUE;VALUE=DATE:20060106
LAST-MODIFIED:20060205T235308Z
SEQUENCE:1
STATUS:NEEDS-ACTION
SUMMARY:Task #2
UID:E10BA47467C5C69BB74E8720@example.com
BEGIN:VALARM
ACTION:AUDIO
TRIGGER;RELATED=START:-PT10M
END:VALARM
END:VTODO
END:VCALENDAR
</C:calendar-data>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://cal.example.com/bernard/work/abcd6.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>"fffff-abcd6"</D:getetag>
<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VTODO
COMPLETED:20051223T122322Z
DTSTAMP:20060205T235400Z
DUE;VALUE=DATE:20051225
LAST-MODIFIED:20060205T235308Z
SEQUENCE:1
STATUS:COMPLETED
SUMMARY:Task #3
UID:E10BA47467C5C69BB74E8722@example.com
END:VTODO
END:VCALENDAR
</C:calendar-data>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://cal.example.com/bernard/work/abcd7.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>"fffff-abcd7"</D:getetag>
<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VTODO
DTSTAMP:20060205T235600Z
DUE;VALUE=DATE:20060101
LAST-MODIFIED:20060205T235308Z
SEQUENCE:1
STATUS:CANCELLED
SUMMARY:Task #4
UID:E10BA47467C5C69BB74E8725@example.com
END:VTODO
END:VCALENDAR
</C:calendar-data>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://cal.example.com/bernard/work/abcd8.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>"fffff-abcd8"</D:getetag>
<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VFREEBUSY
ORGANIZER;CN="Bernard Desruisseaux":mailto:bernard@example.com
UID:76ef34-54a3d2@example.com
DTSTAMP:20050530T123421Z
DTSTART:20060101T000000Z
DTEND:20060108T000000Z
FREEBUSY:20050531T230000Z/20050601T010000Z
FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060102T100000Z/20060102T120000Z
FREEBUSY:20060103T100000Z/20060103T120000Z
FREEBUSY:20060104T100000Z/20060104T120000Z
FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20060105T100000Z/20060105T120000Z
FREEBUSY:20060106T100000Z/20060106T120000Z
END:VFREEBUSY
END:VCALENDAR
</C:calendar-data>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
Authors' Addresses
Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA EMail: cyrus@daboo.name URI: http://www.apple.com/ Bernard Desruisseaux Oracle Corporation 600 Blvd. de Maisonneuve West Suite 1900 Montreal, QC H3A 3J2 CANADA EMail: bernard.desruisseaux@oracle.com URI: http://www.oracle.com/ Lisa Dusseault CommerceNet 169 University Ave. Palo Alto, CA 94301 USA EMail: ldusseault@commerce.net URI: http://commerce.net/
Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.