idnits 2.17.1
draft-ietf-calext-availability-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (November 23, 2015) is 3075 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
No issues found here.
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group C. Daboo
3 Internet-Draft Apple
4 Intended status: Standards Track M. Douglass
5 Expires: May 26, 2016 RPI
6 November 23, 2015
8 Calendar Availability
9 draft-ietf-calext-availability-01
11 Abstract
13 This document specifies a new iCalendar calendar component that
14 allows the publication of available and unavailable time periods
15 associated with a calendar user. This component can be used in
16 standard iCalendar free-busy lookups, including iTIP free-busy
17 requests, to generate repeating blocks of available or busy time with
18 exceptions as needed.
20 This document also defines extensions to CalDAV calendar-access and
21 calendar-auto-schedule which specify how this new calendar component
22 can be used when doing free-busy time evaluation in CalDAV.
24 Editorial Note (To be removed by RFC Editor before publication)
26 Discussion of this specification is taking place on the mailing list
27 http://lists.osafoundation.org/mailman/listinfo/ietf-caldav .
29 Status of This Memo
31 This Internet-Draft is submitted in full conformance with the
32 provisions of BCP 78 and BCP 79.
34 Internet-Drafts are working documents of the Internet Engineering
35 Task Force (IETF). Note that other groups may also distribute
36 working documents as Internet-Drafts. The list of current Internet-
37 Drafts is at http://datatracker.ietf.org/drafts/current/.
39 Internet-Drafts are draft documents valid for a maximum of six months
40 and may be updated, replaced, or obsoleted by other documents at any
41 time. It is inappropriate to use Internet-Drafts as reference
42 material or to cite them other than as "work in progress."
44 This Internet-Draft will expire on May 26, 2016.
46 Copyright Notice
48 Copyright (c) 2015 IETF Trust and the persons identified as the
49 document authors. All rights reserved.
51 This document is subject to BCP 78 and the IETF Trust's Legal
52 Provisions Relating to IETF Documents
53 (http://trustee.ietf.org/license-info) in effect on the date of
54 publication of this document. Please review these documents
55 carefully, as they describe your rights and restrictions with respect
56 to this document. Code Components extracted from this document must
57 include Simplified BSD License text as described in Section 4.e of
58 the Trust Legal Provisions and are provided without warranty as
59 described in the Simplified BSD License.
61 Table of Contents
63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
64 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
65 3. iCalendar Extensions . . . . . . . . . . . . . . . . . . . . 4
66 3.1. VAVAILABILITY Component . . . . . . . . . . . . . . . . . 4
67 3.2. Busy Time Type . . . . . . . . . . . . . . . . . . . . . 10
68 4. Combining VAVAILABILITY components . . . . . . . . . . . . . 10
69 5. Calculating Free-Busy Time . . . . . . . . . . . . . . . . . 11
70 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12
71 6. Use with iTIP . . . . . . . . . . . . . . . . . . . . . . . . 14
72 7. CalDAV Extensions . . . . . . . . . . . . . . . . . . . . . . 14
73 7.1. CalDAV Requirements Overview . . . . . . . . . . . . . . 14
74 7.2. New features in CalDAV . . . . . . . . . . . . . . . . . 15
75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
76 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
78 10.1. Component Registrations . . . . . . . . . . . . . . . . 18
79 10.2. Property Registrations . . . . . . . . . . . . . . . . . 19
80 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
81 12. Normative References . . . . . . . . . . . . . . . . . . . . 19
82 Appendix A. Example Calendar #1 . . . . . . . . . . . . . . . . 20
83 Appendix B. Change History (To be removed by RFC Editor before
84 publication) . . . . . . . . . . . . . . . . . . . . 22
85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
87 1. Introduction
89 Calendar users often have regular periods of time when they are
90 either available to be scheduled or always unavailable. For example,
91 an office worker will often wish only to appear free to their work
92 colleagues during normal 'office hours' (e.g., Monday through Friday,
93 9 am through 5 pm). Or, a university professor might only be
94 available to students during a set period of time (e.g., Thursday
95 afternoons, 2 pm through 5 pm during term time only). Ideally users
96 ought be able to specify such periods directly via their calendar
97 user agent, and have them automatically considered as part of the
98 normal free-busy lookup for that user. In addition, it ought be
99 possible to present different periods of available time depending on
100 which user is making the request.
102 iCalendar [RFC5545] defines a "VFREEBUSY" component that can be used
103 to represent fixed busy time periods, but it does not provide a way
104 to specify a repeating period of available or unavailable time.
105 Since repeating patterns are often the case, "VFREEBUSY" components
106 are not sufficient to solve this problem.
108 This specification defines a new type of iCalendar component that can
109 be used to publish user availability.
111 CalDAV [RFC4791] provides a way for calendar users to access and
112 manage calendar data and exchange this data via scheduling
113 operations. As part of this, the CalDAV calendar-access [RFC4791]
114 feature provides a CALDAV:free-busy-query REPORT that returns free-
115 busy information for a calendar collection or hierarchy of calendar
116 collections. Also, the CalDAV calendar-auto-schedule [RFC6638]
117 feature allows free-busy information for a calendar user to be
118 determined. Both of these operations involve examining user
119 calendars for events that 'block time', with the blocked out periods
120 being returned in a "VFREEBUSY" component.
122 This specification extends the CalDAV calendar-access and CalDAV
123 calendar-auto-schedule features to allow the new iCalendar
124 availability components to be stored and manipulated, and to allow
125 free-busy lookups to use the information from any such components, if
126 present.
128 2. Conventions Used in This Document
130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
132 "OPTIONAL" in this document are to be interpreted as described in
133 [RFC2119].
135 When XML element types in the namespaces "DAV:" and
136 "urn:ietf:params:xml:ns:caldav" are referenced in this document
137 outside of the context of an XML fragment, the string "DAV:" and
138 "CALDAV:" will be prefixed to the element type names respectively.
140 3. iCalendar Extensions
142 This specification adds a new "VAVAILABILITY" calendar component to
143 iCalendar. The "VAVAILABILITY" component is itself a container for
144 new "AVAILABLE" sub-components.
146 The purpose of the "VAVAILABILITY" calendar component is to provide a
147 grouping of available time information over a specific range of time.
148 Within that, there are specific time ranges that are marked as
149 available via a set of "AVAILABLE" calendar sub-components. Together
150 these can be used to specify available time that can repeat over set
151 periods of time, and which can vary over time.
153 An illustration of how "VAVAILABILITY" and "AVAILABLE" components
154 work is shown below.
156 Time-range
157 <=========================================================>
159 +-------------------------------------------------+
160 | VAVAILABILITY |
161 +-------------------------------------------------+
162 +------------+ +------------+
163 | AVAILABLE | | AVAILABLE |
164 +------------+ +------------+
166 <-> <-----> <-----------> Busy Time
168 The overall time-range is shown at the top. A "VAVAILABILITY"
169 component spans part of the range. The time-range covered by the
170 "VAVAILABILITY" component is considered to be busy, except for the
171 ranges covered by the "AVAILABLE" components within the
172 "VAVAILABILITY" component.
174 3.1. VAVAILABILITY Component
176 Component Name: VAVAILABILITY
178 Purpose: Provide a grouping of component properties and sub-
179 components that describe the availability associated with a
180 calendar user.
182 Format Definition: A "VAVAILABILITY" calendar component is defined
183 by the following notation:
185 availabilityc = "BEGIN" ":" "VAVAILABILITY" CRLF
186 availabilityprop *availablec
187 "END" ":" "VAVAILABILITY" CRLF
189 availabilityprop = *(
190 ;
191 ; the following are REQUIRED,
192 ; but MUST NOT occur more than once
193 ;
194 dtstamp / uid
195 ;
196 ; the following are OPTIONAL,
197 ; but MUST NOT occur more than once
198 ;
199 busytype / class / created / description /
200 dtstart / last-mod / organizer /
201 priority /seq / summary / url /
202 ;
203 ; Either 'dtend' or 'duration' MAY appear
204 ; in an 'availableprop', but 'dtend' and
205 ; 'duration' MUST NOT occur in the same
206 ; 'availabilityprop'.
207 ; 'duration' MUST NOT be present if
208 ; 'dtstart' is not present
209 ;
210 dtend / duration /
211 ;
212 ; the following are OPTIONAL,
213 ; and MAY occur more than once
214 ;
215 categories / comment / contact /
216 x-prop / iana-prop
217 ;
218 )
220 availablec = "BEGIN" ":" "AVAILABLE" CRLF
221 availableprop
222 "END" ":" "AVAILABLE" CRLF
224 availableprop = *(
225 ;
226 ; the following are REQUIRED,
227 ; but MUST NOT occur more than once
228 ;
229 dtstamp / dtstart / uid /
230 ;
231 ; Either 'dtend' or 'duration' MAY appear in
232 ; an 'availableprop', but 'dtend' and
233 ; 'duration' MUST NOT occur in the same
234 ; 'availableprop'.
235 ;
236 dtend / duration /
237 ;
238 ; the following are OPTIONAL,
239 ; but MUST NOT occur more than once
240 ;
241 created / description / last-mod /
242 recurid / rrule / summary /
243 ;
244 ; the following are OPTIONAL,
245 ; and MAY occur more than once
246 ;
247 categories / comment / contact / exdate /
248 rdate / x-prop / iana-prop
250 )
252 Description: A "VAVAILABILITY" component indicates a period of time
253 within which availability information is provided. A
254 "VAVAILABILITY" component can specify a start time and an end time
255 or duration. If "DTSTART" is not present, then the start time is
256 unbounded. If "DTEND" or "DURATION" are not present, then the end
257 time is unbounded. Within the specified time period, availability
258 defaults to a free-busy type of "BUSY-UNAVAILABLE" (see
259 Section 3.2), except for any time periods corresponding to
260 "AVAILABLE" sub-components.
262 "AVAILABLE" sub-components are used to indicate periods of free
263 time within the time range of the enclosing "VAVAILABILITY"
264 component. "AVAILABLE" sub-components MAY include recurrence
265 properties to specify recurring periods of time, which can be
266 overridden using normal iCalendar recurrence behavior (i.e., use
267 of the "RECURRENCE-ID" property).
269 If specified, the "DTSTART" and "DTEND" properties in
270 "VAVAILABILITY" components and "AVAILABLE" sub-components MUST be
271 "DATE-TIME" values specified as either date with UTC time or date
272 with local time and a time zone reference.
274 The iCalendar object containing the "VAVAILABILITY" component MUST
275 contain appropriate "VTIMEZONE" components corresponding to each
276 unique "TZID" parameter value used in any DATE-TIME properties in
277 all components.
279 When used to publish available time, the "ORGANIZER" property
280 specifies the calendar user associated with the published
281 available time.
283 If the "PRIORITY" property is specified in "VAVAILABILITY"
284 components, it is used to determine how that component is combined
285 with other "VAVAILABILITY" components. See Section 4.
287 Other calendar properties MAY be specified in "VAVAILABILITY" or
288 "AVAILABLE" components and are considered attributes of the marked
289 block of time. Their usage is application specific. For example,
290 the "LOCATION" property might be used to indicate that a person is
291 available in one location for part of the week and a different
292 location for another part of the week.
294 Example: The following is an example of a "VAVAILABILITY" calendar
295 component used to represent the availability of a user, always
296 available Monday through Friday, 9:00 AM to 5:00 PM in the
297 America/Montreal time zone:
299 BEGIN:VAVAILABILITY
300 ORGANIZER:mailto:bernard@example.com
301 UID:vavail-1@example.com
302 DTSTAMP:20111005T133225Z
303 BEGIN:AVAILABLE
304 UID:avail-1-A@example.com
305 SUMMARY:Monday to Friday from 9:00 to 17:00
306 DTSTART;TZID=America/Montreal:20111002T090000
307 DTEND;TZID=America/Montreal:20111002T170000
308 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
309 END:AVAILABLE
310 END:VAVAILABILITY
312 The following is an example of a "VAVAILABILITY" calendar
313 component used to represent the availability of a user available
314 Monday through Thursday, 9:00 AM to 5:00 PM at the main office,
315 and Friday 9:00 AM to 12:00 PM in the branch office in the
316 America/Montreal time zone between October 2nd and December 2nd
317 2011:
319 BEGIN:VAVAILABILITY
320 ORGANIZER:mailto:bernard@example.com
321 UID:vavail-1@example.com
322 DTSTAMP:20111005T133225Z
323 DTSTART;TZID=America/Montreal:20111002T000000
324 DTEND;TZID=America/Montreal:20111202T000000
325 BEGIN:AVAILABLE
326 UID:avail-1-A@example.com
327 SUMMARY:Monday to Thursday from 9:00 to 17:00
328 DTSTART;TZID=America/Montreal:20111002T090000
329 DTEND;TZID=America/Montreal:20111002T170000
330 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH
331 LOCATION:Main Office
332 END:AVAILABLE
333 BEGIN:AVAILABLE
334 UID:avail-1-B@example.com
335 SUMMARY:Friday from 9:00 to 12:00
336 DTSTART;TZID=America/Montreal:20111006T090000
337 DTEND;TZID=America/Montreal:20111006T120000
338 RRULE:FREQ=WEEKLY
339 LOCATION:Branch Office
340 END:AVAILABLE
341 END:VAVAILABILITY
343 The following is an example of three "VAVAILABILITY" calendar
344 components used to represent the availability of a traveling
345 worker: Monday through Friday, 9:00 AM to 5:00 PM each day.
346 However, for three weeks the calendar user is working in Montreal,
347 then one week in Los Angeles, then back to Montreal. Note that
348 each overall period is covered by separate "VAVAILABILITY"
349 components. The last of these has no DTEND so continues on "for
350 ever". This example shows one way "blocks" of available time can
351 be represented. See Section 4 for another approach using
352 priorities.
354 BEGIN:VAVAILABILITY
355 ORGANIZER:mailto:bernard@example.com
356 UID:vavail-1@example.com
357 DTSTAMP:20111005T133225Z
358 DTSTART;TZID=America/Montreal:20111002T000000
359 DTEND;TZID=America/Montreal:20111023T030000
360 BEGIN:AVAILABLE
361 UID:avail-1-A@example.com
362 SUMMARY:Monday to Friday from 9:00 to 17:00
363 DTSTART;TZID=America/Montreal:20111002T090000
364 DTEND;TZID=America/Montreal:20111002T170000
365 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
366 LOCATION:Montreal
367 END:AVAILABLE
368 END:VAVAILABILITY
369 BEGIN:VAVAILABILITY
370 ORGANIZER:mailto:bernard@example.com
371 UID:vavail-2@example.com
372 DTSTAMP:20111005T133225Z
373 DTSTART;TZID=America/Los_Angeles:20111023T000000
374 DTEND;TZID=America/Los_Angeles:20111030T000000
375 BEGIN:AVAILABLE
376 UID:avail-2-A@example.com
377 SUMMARY:Monday to Friday from 9:00 to 17:00
378 DTSTART;TZID=America/Los_Angeles:20111023T090000
379 DTEND;TZID=America/Los_Angeles:20111023T170000
380 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
381 LOCATION:Los Angeles
382 END:AVAILABLE
383 END:VAVAILABILITY
384 BEGIN:VAVAILABILITY
385 ORGANIZER:mailto:bernard@example.com
386 UID:vavail-3@example.com
387 DTSTAMP:20111005T133225Z
388 DTSTART;TZID=America/Montreal:20111030T030000
389 BEGIN:AVAILABLE
390 UID:avail-3-A@example.com
391 SUMMARY:Monday to Friday from 9:00 to 17:00
392 DTSTART;TZID=America/Montreal:20111030T090000
393 DTEND;TZID=America/Montreal:20111030T170000
394 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
395 LOCATION:Montreal
396 END:AVAILABLE
397 END:VAVAILABILITY
399 3.2. Busy Time Type
401 Property Name: BUSYTYPE
403 Purpose: This property specifies the default busy time type.
405 Value Type: TEXT
407 Property Parameters: IANA and non-standard property parameters can
408 be specified on this property.
410 Conformance: This property can be specified within "VAVAILABILITY"
411 calendar components.
413 Format Definition: This property is defined by the following
414 notation:
416 busytype = "BUSYTYPE" busytypeparam ":" busytypevalue CRLF
418 busytypeparam = *(";" other-param)
420 busytypevalue = "BUSY" / "BUSY-UNAVAILABLE" /
421 "BUSY-TENTATIVE" / iana-token / x-name
422 ; Default is "BUSY-UNAVAILABLE".
424 Description: This property is used to specify the default busy time
425 type. The values correspond to those used by the "FBTYPE"
426 parameter used on a "FREEBUSY" property, with the exception that
427 the "FREE" value is not used in this property. If not specified
428 on a component that allows this property, the default is "BUSY-
429 UNAVAILABLE".
431 Example: The following is an example of this property:
433 BUSYTYPE:BUSY
435 4. Combining VAVAILABILITY components
437 The "VAVAILABILITY" component allows a calendar user to describe
438 their availability over extended periods of time through the use of
439 recurrence patterns. This availability might be relatively constant
440 from year to year.
442 However, there is usually some degree of irregularity, as people take
443 vacations or perhaps spend a few weeks at a different office. For
444 that period of time there is a need to redefine their availability.
446 Rather than modify their existing availability, the "PRIORITY"
447 property allows new "VAVAILABILITY" components to override others of
448 lower ordinal priority. Note that iCalendar [RFC5545] defines the
449 "PRIORITY" property such that a value of 0 is undefined, 1 is the
450 highest priority and 9 is the lowest.
452 When combining "VAVAILABILITY" components, an absence of a "PRIORITY"
453 property or a value of 0 implies the lowest level of priority. When
454 two or more VAVAILABILITY components overlap, and they have the same
455 PRIORITY value, the overlapping busy time type is determined by the
456 following order: BUSY > BUSY-UNAVAILABLE > BUSY-TENTATIVE. i.e., if
457 one component has a BUSYTYPE set to BUSY, and the another has
458 BUSYTYPE set to BUSY-UNAVAILABLE, then the effective busy time type
459 over the time range that they overlap would be BUSY. It is up to the
460 creator of such components to ensure that combining them produces a
461 consistent and expected result.
463 To calculate the available time, order the intersecting
464 "VAVAILABILITY" components by priority (i.e., lowest to highest
465 "PRIORITY" values are 0, 9, 8, 7, 6, 5, 4, 3, 2, 1).
467 Step through the resulting list of "VAVAILABILITY" components. For
468 each, the time range covered by the "VAVAILABILITY" component is set
469 to busy and then portions of it defined by the "AVAILABLE" components
470 in the "VAVAILABILITY" component are set to free.
472 Note that, if any "VAVAILABILITY" component completely covers the
473 date range of interest, then any lower priority "VAVAILABILITY"
474 components can be ignored.
476 5. Calculating Free-Busy Time
478 This section describes how free-busy time information for a calendar
479 user is calculated in the presence of "VAVAILABILITY" calendar
480 components.
482 An iCalendar "VFREEBUSY" component is used to convey "rolled-up"
483 free-busy time information for a calendar user. This can be
484 generated as the result of an iTIP free-busy [RFC5546] request or
485 through some other mechanism (e.g., a CalDAV calendar-access
486 CALDAV:free-busy-query REPORT).
488 When one or more "VAVAILABILITY" components are present and intersect
489 the time-range for the free-busy request, first available time is
490 calculated, as outlined in Section 4. Once that is done, regular
491 "VEVENT" and "VFREEBUSY" components can be "overlaid" in the usual
492 way to block out time.
494 An example procedure for this is as follows:
496 1. Initially mark the entire period of the free-busy request as
497 free.
499 2. For each "VAVAILABILITY" component ordered by PRIORITY:
501 1. Determine if the "VAVAILABILITY" intersects the time-range of
502 the free-busy request. If not ignore it.
504 2. Determine if the "VAVAILABILITY" is completely overridden by
505 a higher priority component. If so ignore it.
507 3. For the time period covered by the "VAVAILABILITY" component,
508 mark time in the free-busy request result set as busy, using
509 the busy time type derived from the "BUSYTYPE" property in
510 the "VAVAILABILITY" component.
512 3. For each remaining "VAVAILABILITY" component in order:
514 1. For each "AVAILABLE" component in the "VAVAILABILITY"
515 component:
517 1. Expand all recurring instances, taking into account
518 overridden instances, ignoring instances or parts of
519 instances that fall outside of the free-busy request
520 time-range or the time period specified by the
521 "VAVAILABILITY" component.
523 2. For each instance, mark the corresponding time in the
524 free-busy request result set as free.
526 4. For each "VEVENT" or "VFREEBUSY" component apply normal free-busy
527 processing within the free-busy request time-range.
529 5.1. Examples
531 In the examples below a table is used to represent time slots for the
532 period of a free-busy request. Each time slot is two hours long.
533 The column header represents the hours from midnight local time.
534 Each row below the column headers represents a step in the free-busy
535 result set determination, following the procedure outlined above.
537 Each cell in the rows below the column header contains a single
538 character that represents the free-busy type for the corresponding
539 time period at the end of the process step represented by the row.
540 The characters in the row are:
542 +-----------+--------------------------------------------------+
543 | Character | Meaning |
544 +-----------+--------------------------------------------------+
545 | F | Represents "FREE" time in that slot. |
546 | B | Represents "BUSY" time in that slot. |
547 | U | Represents "BUSY-UNAVAILABLE" time in that slot. |
548 | T | Represents "BUSY-TENTATIVE" time in that slot. |
549 +-----------+--------------------------------------------------+
551 5.1.1. Simple Example
553 A free-busy request for Monday, 6th November 2011, midnight to
554 midnight in the America/Montreal timezone.
556 The user's calendar is as shown in Appendix A. This includes one
557 "VAVAILABILITY" component giving available time within the requested
558 time-range of 8:00 AM to 6:00 PM, together with one "VEVENT"
559 component representing a two hour meeting starting at 12:00 PM.
561 +------+----+----+----+----+----+----+----+----+----+----+----+----+
562 | Step | 0 | 2 | 4 | 6 | 8 | 10 | 12 | 14 | 16 | 18 | 20 | 22 |
563 +------+----+----+----+----+----+----+----+----+----+----+----+----+
564 | 1. | F | F | F | F | F | F | F | F | F | F | F | F |
565 | 2. | U | U | U | U | U | U | U | U | U | U | U | U |
566 | 3. | U | U | U | U | F | F | F | F | F | U | U | U |
567 | 4. | U | U | U | U | F | F | B | F | F | U | U | U |
568 +------+----+----+----+----+----+----+----+----+----+----+----+----+
570 5.1.2. Further Example
572 The following is another way to represent the availability of the
573 traveling worker shown above. Here we represent their base
574 availability of Monday through Friday, 9:00 AM to 5:00 PM each day
575 with a "VAVAILABILITY" with default "PRIORITY" (there is no "DTEND"
576 property so that this availability is unbounded). For the three
577 weeks the calendar user is working in Los Angeles, we represent their
578 availability with a "VAVAILABILITY" component with priority 1, which
579 overrides the base availability.
581 BEGIN:VAVAILABILITY
582 ORGANIZER:mailto:bernard@example.com
583 UID:vavail-1@example.com
584 DTSTAMP:20111005T133225Z
585 DTSTART;TZID=America/Montreal:20111002T000000
586 BEGIN:AVAILABLE
587 UID:avail-1-A@example.com
588 SUMMARY:Monday to Friday from 9:00 to 17:00
589 DTSTART;TZID=America/Montreal:20111002T090000
590 DTEND;TZID=America/Montreal:20111002T170000
591 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
592 LOCATION:Montreal
593 END:AVAILABLE
594 END:VAVAILABILITY
595 BEGIN:VAVAILABILITY
596 ORGANIZER:mailto:bernard@example.com
597 UID:vavail-2@example.com
598 DTSTAMP:20111005T133225Z
599 DTSTART;TZID=America/Los_Angeles:20111023T000000
600 DTEND;TZID=America/Los_Angeles:20111030T000000
601 BEGIN:AVAILABLE
602 UID:avail-2-A@example.com
603 SUMMARY:Monday to Friday from 9:00 to 17:00
604 DTSTART;TZID=America/Los_Angeles:20111023T090000
605 DTEND;TZID=America/Los_Angeles:20111023T170000
606 PRIORITY:1
607 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
608 LOCATION:Los Angeles
609 END:AVAILABLE
610 END:VAVAILABILITY
612 6. Use with iTIP
614 This specification does not define how "VAVAILABILITY" components are
615 used in scheduling messages sent using the iTIP [RFC5546] protocol.
616 It is expected that future specifications will define how iTIP
617 scheduling can make use of "VAVAILABILITY" components.
619 7. CalDAV Extensions
621 7.1. CalDAV Requirements Overview
623 This section lists what functionality is required of a CalDAV server
624 which supports "VAVAILBILITY" components in stored calendar data. A
625 server:
627 o MUST advertise support for "VAVAILABILITY" components in
628 CALDAV:supported-calendar-component-set properties on calendars
629 which allow storing of such components;
631 o MUST support CALDAV:free-busy-query REPORTs that aggregate the
632 information in any "VAVAILABILITY" components in the calendar
633 collections targeted by the request;
635 o MUST support "VAVAILABILITY" components stored in a
636 CALDAV:calendar-availability WebDAV property on a CALDAV
637 scheduling inbox collection, if the CALDAV calendar-auto-schedule
638 feature is supported;
640 o MUST support iTIP [RFC5546] free-busy requests that aggregate the
641 information in any "VAVAILABILITY" components in calendar
642 collections that contribute to free-busy, or in any
643 "VAVAILABILITY" components stored in the CALDAV:calendar-
644 availability property on the CALDAV scheduling inbox collection of
645 the calendar user targeted by the iTIP free-busy request, if the
646 CalDAV calendar-auto-schedule feature is available.
648 "VAVAILABILITY" components are treated in a manner similar to
649 "VEVENT" and "VTODO" components, and MUST satisfy the other
650 requirements CalDAV imposes on calendar object resources (see
651 Section 4.1 of [RFC4791]).
653 7.2. New features in CalDAV
655 7.2.1. Calendar Availability Support
657 A server supporting the features described in this document MUST
658 include "calendar-availability" as a field in the DAV response header
659 from an OPTIONS request. A value of "calendar-availability" in the
660 DAV response header MUST indicate that the server supports all MUST
661 level requirements specified in this document.
663 7.2.1.1. Example: Using OPTIONS for the Discovery of Calendar
664 Availability Support
666 >> Request <<
668 OPTIONS /home/bernard/calendars/ HTTP/1.1
669 Host: cal.example.com
670 >> Response <<
672 HTTP/1.1 200 OK
673 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
674 Allow: PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL
675 DAV: 1, 2, 3, access-control, calendar-access,
676 calendar-availability
677 Date: Fri, 11 Nov 2005 09:32:12 GMT
678 Content-Length: 0
680 In this example, the OPTIONS method returns the value "calendar-
681 availability" in the DAV response header to indicate that the
682 collection "/home/bernard/calendars/" supports the new features
683 defined in this specification.
685 7.2.2. CALDAV:free-busy-query REPORT
687 A CALDAV:free-busy-query REPORT can be executed on a calendar
688 collection that contains iCalendar "VAVAILABILITY" components. When
689 that occurs, the server MUST aggregate the information in any
690 "VAVAILABILITY" components when generating the free-busy response, as
691 described in Section 5.
693 7.2.3. CALDAV:calendar-availability Property
695 Name: calendar-availability
697 Namespace: urn:ietf:params:xml:ns:caldav
699 Purpose: Defines a "VAVAILABILITY" component that will be used in
700 calculating free-busy time when an iTIP free-busy request is
701 targeted at the calendar user who owns the Inbox.
703 Conformance: This property MAY be protected and SHOULD NOT be
704 returned by a PROPFIND DAV:allprop request. Support for this
705 property is REQUIRED. The value of this property MUST be a valid
706 iCalendar object containing "VAVAILABILITY" components and
707 "VTIMEZONE" components (if required) only.
709 Description: This property allows a user to specify their
710 availability by including an "VAVAILABILITY" component in the
711 value of this property. If present, the server MUST use this
712 "VAVAILABILITY" component when determining free-busy information
713 as part of an iTIP free-busy request being handled by the server.
714 Fot simplicity, only a single "VAVAILABILITY" component MUST be
715 present in the property. For more complex availability scenarios,
716 clients can store multiple "VAVAILABILITY" components in the
717 calendar user's calendar collections.
719 Definition:
721
722 ; Data value MUST be iCalendar object containing
723 ; "VAVAILABILITY" or "VTIMEZONE" components.
725 Example:
727 BEGIN:VCALENDAR
730 CALSCALE:GREGORIAN
731 PRODID:-//example.com//iCalendar 2.0//EN
732 VERSION:2.0
733 BEGIN:VTIMEZONE
734 LAST-MODIFIED:20040110T032845Z
735 TZID:America/Montreal
736 BEGIN:DAYLIGHT
737 DTSTART:20000404T020000
738 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
739 TZNAME:EDT
740 TZOFFSETFROM:-0500
741 TZOFFSETTO:-0400
742 END:DAYLIGHT
743 BEGIN:STANDARD
744 DTSTART:20001026T020000
745 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
746 TZNAME:EST
747 TZOFFSETFROM:-0400
748 TZOFFSETTO:-0500
749 END:STANDARD
750 END:VTIMEZONE
751 BEGIN:VAVAILABILITY
752 UID:vavail-1@example.com
753 DTSTAMP:20111005T133225Z
754 DTSTART;TZID=America/Montreal:20111002T000000
755 BEGIN:AVAILABLE
756 UID:avail-1-A@example.com
757 SUMMARY:Monday to Friday from 9:00 to 18:00
758 DTSTART;TZID=America/Montreal:20111002T090000
759 DTEND;TZID=America/Montreal:20111002T180000
760 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
761 END:AVAILABLE
762 END:VAVAILABILITY
763 END:VCALENDAR
764
766 7.2.4. iTIP free-busy requests
768 The [RFC6638] processing of an iTIP free-busy request targeted at the
769 owner of the CALDAV:schedule-inbox will include free-busy information
770 derived from "VAVAILABILITY" components in any calendar collection
771 targeted during the request, as described in Section 5. In addition,
772 any "VAVAILABILITY" component specified in the CALDAV:calendar-
773 availability property on the owner's Inbox, MUST be included in the
774 free-busy calculation.
776 8. Security Considerations
778 Calculation of availability information, particularly with multiple
779 overlapping time-ranges, can be complex, and CalDAV servers MAY limit
780 the complexity of such data stored by a client.
782 An attacker able to "inject" availability information into a calendar
783 user's calendar data could ensure that the user never appears free
784 for meetings, or appears free at inappropriate times. Calendar
785 systems MUST ensure that availability information for a calendar user
786 can only be modified by authorized users.
788 Beyond this, this specification does not add any additional security
789 issues that are not already present in [RFC5545], [RFC5546],
790 [RFC4791] and [RFC6638].
792 9. Privacy Considerations
794 Normal free-busy information generated from "VAVAILABILITY"
795 components MUST NOT include information other than busy or free time
796 periods. In particular, user specified property values such as
797 "SUMMARY", "LOCATION" and "DESCRIPTION" MUST NOT be copied into the
798 free-busy result data.
800 Free-busy and availability information can be used by attackers to
801 infer the whereabouts or overall level of "activity" of the
802 corresponding calendar user. Any calendar system that allows a user
803 to expose their free-busy and availability information MUST limit
804 access to that information to only authorized users.
806 10. IANA Considerations
808 10.1. Component Registrations
810 This documents defines the following new iCalendar components to be
811 added to the registry defined in Section 8.2.2 of [RFC5545]:
813 +---------------+---------+-----------------------+
814 | Component | Status | Reference |
815 +---------------+---------+-----------------------+
816 | VAVAILABILITY | Current | RFCXXXX, Section 3.1 |
817 | AVAILABLE | Current | RFCXXXX, Section 3.1 |
818 +---------------+---------+-----------------------+
820 10.2. Property Registrations
822 This documents defines the following new iCalendar properties to be
823 added to the registry defined in Section 8.2.3 of [RFC5545]:
825 +----------+---------+-----------------------+
826 | Property | Status | Reference |
827 +----------+---------+-----------------------+
828 | BUSYTYPE | Current | RFCXXXX, Section 3.2 |
829 +----------+---------+-----------------------+
831 11. Acknowledgments
833 Thanks to the following for providing feedback: Toby Considine
834 Bernard Desruisseaux, Evert Pot, Dave Thewlis. This specification
835 came about via discussions at the Calendaring and Scheduling
836 Consortium.
838 12. Normative References
840 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
841 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
842 RFC2119, March 1997,
843 .
845 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
846 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, DOI
847 10.17487/RFC4791, March 2007,
848 .
850 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
851 Scheduling Core Object Specification (iCalendar)", RFC
852 5545, DOI 10.17487/RFC5545, September 2009,
853 .
855 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
856 Interoperability Protocol (iTIP)", RFC 5546, DOI 10.17487/
857 RFC5546, December 2009,
858 .
860 [RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to
861 CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012,
862 .
864 Appendix A. Example Calendar #1
865 iCalendar object
867 BEGIN:VCALENDAR
868 CALSCALE:GREGORIAN
869 PRODID:-//example.com//iCalendar 2.0//EN
870 VERSION:2.0
871 BEGIN:VTIMEZONE
872 LAST-MODIFIED:20040110T032845Z
873 TZID:America/Montreal
874 BEGIN:DAYLIGHT
875 DTSTART:20000404T020000
876 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
877 TZNAME:EDT
878 TZOFFSETFROM:-0500
879 TZOFFSETTO:-0400
880 END:DAYLIGHT
881 BEGIN:STANDARD
882 DTSTART:20001026T020000
883 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
884 TZNAME:EST
885 TZOFFSETFROM:-0400
886 TZOFFSETTO:-0500
887 END:STANDARD
888 END:VTIMEZONE
889 BEGIN:VEVENT
890 DTSTAMP:20111113T044111Z
891 DTSTART;TZID=America/Montreal:20111106T120000
892 DURATION:PT1H
893 SUMMARY:Meeting
894 UID:60A48841ECB90F3F215FE3D2@example.com
895 END:VEVENT
896 BEGIN:VAVAILABILITY
897 UID:vavail-1@example.com
898 DTSTAMP:20111005T133225Z
899 DTSTART;TZID=America/Montreal:20111002T000000
900 BEGIN:AVAILABLE
901 UID:avail-1-A@example.com
902 SUMMARY:Monday to Friday from 9:00 to 18:00
903 DTSTART;TZID=America/Montreal:20111002T090000
904 DTEND;TZID=America/Montreal:20111002T180000
905 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
906 END:AVAILABLE
907 END:VAVAILABILITY
908 END:VCALENDAR
910 Appendix B. Change History (To be removed by RFC Editor before
911 publication)
913 Changes in draft-ietf-calext-availability-01:
915 1. Minor editorial fixes.
917 2. ABNF syntax fixes.
919 3. Clarify BUSTYPE precedence when combining components with the
920 same PRIORITY values.
922 4. Added section explaining that iTIP use is not defined
924 5. Added Privacy Considerations and tweaked Security Considerations.
926 6. Added diagram to illustrate the overall concept.
928 7. Limit the calendar-availability property to a single
929 "VAVAILABILITY" component.
931 Changes in draft-ietf-calext-availability-00:
933 1. Re-publication as WG document.
935 Changes in draft-daboo-calendar-availability-05:
937 1. Small typos.
939 2. Fix explanation of priority.
941 3. Change uid values to make legal and easier to follow.
943 Changes in draft-daboo-calendar-availability-04:
945 1. Small typos.
947 2. Add prioritized example.
949 Changes in draft-daboo-calendar-availability-03:
951 1. Switch authors.
953 2. CalDAV scheduling is now rfc6638.
955 3. List priority as a vavailability property and define its use.
957 Changes in draft-daboo-calendar-availability-02:
959 1. Updated to 5545/5546 references.
961 2. Fixed some examples.
963 3. Added some more properties to the components
965 4. Fixed text that said dtstart was required in VAVAILABILITY
967 Changes in draft-daboo-calendar-availability-01:
969 1. Allow property on Inbox for caldav-schedule.
971 2. Clarify that DURATION can only be present in VAVAILABILITY if
972 DTSTART is also present, and DTEND is not.
974 3. Updated references.
976 4. Added templates.
978 Authors' Addresses
980 Cyrus Daboo
981 Apple Inc.
982 1 Infinite Loop
983 Cupertino, CA 95014
984 USA
986 Email: cyrus@daboo.name
987 URI: http://www.apple.com/
989 Michael Douglass
990 Rensselaer Polytechnic Institute
991 110 8th Street
992 Troy, NY 12180
993 USA
995 Email: douglm@rpi.edu
996 URI: http://www.rpi.edu/