idnits 2.17.1
draft-ietf-calext-availability-04.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 :
----------------------------------------------------------------------------
-- The draft header indicates that this document updates RFC6638, but the
abstract doesn't seem to directly say this. It does mention RFC6638
though, so this could be OK.
-- The draft header indicates that this document updates RFC5545, but the
abstract doesn't seem to directly say this. It does mention RFC5545
though, so this could be OK.
-- The draft header indicates that this document updates RFC4791, but the
abstract doesn't seem to directly say this. It does mention RFC4791
though, so this could be OK.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
(Using the creation date from RFC4791, updated by this document, for
RFC5378 checks: 2004-06-24)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (July 7, 2016) is 2842 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)
== Missing Reference: 'OPSDIR' is mentioned on line 1010, but not defined
== Missing Reference: 'IESG' is mentioned on line 1014, but not defined
== Missing Reference: 'EXPERT' is mentioned on line 1037, but not defined
== Missing Reference: 'WGCHAIR' is mentioned on line 1043, but not defined
== Missing Reference: 'WGLC' is mentioned on line 1053, but not defined
Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--).
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 Updates: 5545,4791,6638 (if approved) M. Douglass
5 Intended status: Standards Track Spherical Cow Group
6 Expires: January 8, 2017 July 7, 2016
8 Calendar Availability
9 draft-ietf-calext-availability-04
11 Abstract
13 This document specifies a new iCalendar (RFC 5545) calendar component
14 that 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 (RFC 5546 )
17 free-busy requests, to generate repeating blocks of available or busy
18 time with exceptions as needed.
20 This document also defines extensions to Calendaring Extensions to
21 WebDAV (CalDAV) calendar access protocol (RFC 4791) and the
22 associated scheduling protocol (RFC 6638) to specify how this new
23 calendar component can be used when evaluating free-busy time.
25 Editorial Note (To be removed by RFC Editor before publication)
27 Discussion of this specification is taking place on the mailing list
28 http://lists.osafoundation.org/mailman/listinfo/ietf-caldav .
30 Status of This Memo
32 This Internet-Draft is submitted in full conformance with the
33 provisions of BCP 78 and BCP 79.
35 Internet-Drafts are working documents of the Internet Engineering
36 Task Force (IETF). Note that other groups may also distribute
37 working documents as Internet-Drafts. The list of current Internet-
38 Drafts is at http://datatracker.ietf.org/drafts/current/.
40 Internet-Drafts are draft documents valid for a maximum of six months
41 and may be updated, replaced, or obsoleted by other documents at any
42 time. It is inappropriate to use Internet-Drafts as reference
43 material or to cite them other than as "work in progress."
45 This Internet-Draft will expire on January 8, 2017.
47 Copyright Notice
49 Copyright (c) 2016 IETF Trust and the persons identified as the
50 document authors. All rights reserved.
52 This document is subject to BCP 78 and the IETF Trust's Legal
53 Provisions Relating to IETF Documents
54 (http://trustee.ietf.org/license-info) in effect on the date of
55 publication of this document. Please review these documents
56 carefully, as they describe your rights and restrictions with respect
57 to this document. Code Components extracted from this document must
58 include Simplified BSD License text as described in Section 4.e of
59 the Trust Legal Provisions and are provided without warranty as
60 described in the Simplified BSD License.
62 Table of Contents
64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
65 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
66 3. iCalendar Extensions . . . . . . . . . . . . . . . . . . . . 4
67 3.1. VAVAILABILITY Component . . . . . . . . . . . . . . . . . 4
68 3.2. Busy Time Type . . . . . . . . . . . . . . . . . . . . . 10
69 4. Combining VAVAILABILITY components . . . . . . . . . . . . . 10
70 5. Calculating Free-Busy Time . . . . . . . . . . . . . . . . . 12
71 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 13
72 6. Use with iTIP . . . . . . . . . . . . . . . . . . . . . . . . 15
73 7. CalDAV Extensions . . . . . . . . . . . . . . . . . . . . . . 15
74 7.1. CalDAV Requirements Overview . . . . . . . . . . . . . . 15
75 7.2. New features in CalDAV . . . . . . . . . . . . . . . . . 15
76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
77 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
79 10.1. Component Registrations . . . . . . . . . . . . . . . . 20
80 10.2. Property Registrations . . . . . . . . . . . . . . . . . 20
81 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
82 12. Normative References . . . . . . . . . . . . . . . . . . . . 20
83 Appendix A. Example Calendar #1 . . . . . . . . . . . . . . . . 21
84 Appendix B. Example Calendar #2 . . . . . . . . . . . . . . . . 21
85 Appendix C. Change History (To be removed by RFC Editor before
86 publication) . . . . . . . . . . . . . . . . . . . . 23
87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
89 1. Introduction
91 Calendar users often have regular periods of time when they are
92 either available to be scheduled or always unavailable. For example,
93 an office worker will often wish only to appear free to their work
94 colleagues during normal 'office hours' (e.g., Monday through Friday,
95 9 am through 5 pm). Or, a university professor might only be
96 available to students during a set period of time (e.g., Thursday
97 afternoons, 2 pm through 5 pm during term time only). Ideally users
98 ought be able to specify such periods directly via their calendar
99 user agent, and have them automatically considered as part of the
100 normal free-busy lookup for that user. In addition, it ought be
101 possible to present different periods of available time depending on
102 which user is making the request.
104 iCalendar [RFC5545] defines a "VFREEBUSY" component that can be used
105 to represent fixed busy time periods, but it does not provide a way
106 to specify a repeating period of available or unavailable time.
107 Since repeating patterns are often the case, "VFREEBUSY" components
108 are not sufficient to solve this problem.
110 This specification defines a new type of iCalendar component that can
111 be used to publish user availability.
113 CalDAV [RFC4791] provides a way for calendar users to access and
114 manage calendar data and exchange this data via scheduling
115 operations. As part of this, the CalDAV calendar-access [RFC4791]
116 feature provides a CALDAV:free-busy-query REPORT that returns free-
117 busy information for a calendar collection or hierarchy of calendar
118 collections. Also, the CalDAV calendar-auto-schedule [RFC6638]
119 feature allows free-busy information for a calendar user to be
120 determined. Both of these operations involve examining user
121 calendars for events that 'block time', with the blocked out periods
122 being returned in a "VFREEBUSY" component.
124 This specification extends the CalDAV calendar-access and CalDAV
125 calendar-auto-schedule features to allow the new iCalendar
126 availability components to be stored and manipulated, and to allow
127 free-busy lookups to use the information from any such components, if
128 present.
130 2. Conventions Used in This Document
132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
134 "OPTIONAL" in this document are to be interpreted as described in
135 [RFC2119].
137 When XML element types in the namespaces "DAV:" and
138 "urn:ietf:params:xml:ns:caldav" are referenced in this document
139 outside of the context of an XML fragment, the string "DAV:" and
140 "CALDAV:" will be prefixed to the element type names respectively.
142 3. iCalendar Extensions
144 This specification adds a new "VAVAILABILITY" calendar component to
145 iCalendar. The "VAVAILABILITY" component is itself a container for
146 new "AVAILABLE" sub-components.
148 The purpose of the "VAVAILABILITY" calendar component is to provide a
149 grouping of available time information over a specific range of time.
150 Within that, there are specific time ranges that are marked as
151 available via a set of "AVAILABLE" calendar sub-components. Together
152 these can be used to specify available time that can repeat over set
153 periods of time, and which can vary over time.
155 An illustration of how "VAVAILABILITY" and "AVAILABLE" components
156 work is shown below.
158 Time-range
159 <=========================================================>
161 +-------------------------------------------------+
162 | VAVAILABILITY |
163 +-------------------------------------------------+
164 +------------+ +------------+
165 | AVAILABLE | | AVAILABLE |
166 +------------+ +------------+
168 <-> <-----> <-----------> Busy Time
170 The overall time-range is shown at the top. A "VAVAILABILITY"
171 component spans part of the range. The time-range covered by the
172 "VAVAILABILITY" component is considered to be busy, except for the
173 ranges covered by the "AVAILABLE" components within the
174 "VAVAILABILITY" component.
176 3.1. VAVAILABILITY Component
178 Component Name: VAVAILABILITY
180 Purpose: Provide a grouping of component properties and sub-
181 components that describe the availability associated with a
182 calendar user.
184 Format Definition: A "VAVAILABILITY" calendar component is defined
185 by the following notation:
187 availabilityc = "BEGIN" ":" "VAVAILABILITY" CRLF
188 availabilityprop *availablec
189 "END" ":" "VAVAILABILITY" CRLF
191 availabilityprop = *(
192 ;
193 ; the following are REQUIRED,
194 ; but MUST NOT occur more than once
195 ;
196 dtstamp / uid
197 ;
198 ; the following are OPTIONAL,
199 ; but MUST NOT occur more than once
200 ;
201 busytype / class / created / description /
202 dtstart / last-mod / location / organizer /
203 priority /seq / summary / url /
204 ;
205 ; Either 'dtend' or 'duration' MAY appear
206 ; in an 'availableprop', but 'dtend' and
207 ; 'duration' MUST NOT occur in the same
208 ; 'availabilityprop'.
209 ; 'duration' MUST NOT be present if
210 ; 'dtstart' is not present
211 ;
212 dtend / duration /
213 ;
214 ; the following are OPTIONAL,
215 ; and MAY occur more than once
216 ;
217 categories / comment / contact /
218 x-prop / iana-prop
219 ;
220 )
222 availablec = "BEGIN" ":" "AVAILABLE" CRLF
223 availableprop
224 "END" ":" "AVAILABLE" CRLF
226 availableprop = *(
227 ;
228 ; the following are REQUIRED,
229 ; but MUST NOT occur more than once
230 ;
231 dtstamp / dtstart / uid /
232 ;
233 ; Either 'dtend' or 'duration' MAY appear in
234 ; an 'availableprop', but 'dtend' and
235 ; 'duration' MUST NOT occur in the same
236 ; 'availableprop'.
237 ;
238 dtend / duration /
239 ;
240 ; the following are OPTIONAL,
241 ; but MUST NOT occur more than once
242 ;
243 created / description / last-mod /
244 location / recurid / rrule / summary /
245 ;
246 ; the following are OPTIONAL,
247 ; and MAY occur more than once
248 ;
249 categories / comment / contact / exdate /
250 rdate / x-prop / iana-prop
251 ;
252 )
254 Description: A "VAVAILABILITY" component indicates a period of time
255 within which availability information is provided. A
256 "VAVAILABILITY" component can specify a start time and an end time
257 or duration. If "DTSTART" is not present, then the start time is
258 unbounded. If "DTEND" or "DURATION" are not present, then the end
259 time is unbounded. Within the specified time period, availability
260 defaults to a free-busy type of "BUSY-UNAVAILABLE" (see
261 Section 3.2), except for any time periods corresponding to
262 "AVAILABLE" sub-components.
264 "AVAILABLE" sub-components are used to indicate periods of free
265 time within the time range of the enclosing "VAVAILABILITY"
266 component. "AVAILABLE" sub-components MAY include recurrence
267 properties to specify recurring periods of time, which can be
268 overridden using normal iCalendar recurrence behavior (i.e., use
269 of the "RECURRENCE-ID" property).
271 If specified, the "DTSTART" and "DTEND" properties in
272 "VAVAILABILITY" components and "AVAILABLE" sub-components MUST be
273 "DATE-TIME" values specified as either date with UTC time or date
274 with local time and a time zone reference.
276 The iCalendar object containing the "VAVAILABILITY" component MUST
277 contain appropriate "VTIMEZONE" components corresponding to each
278 unique "TZID" parameter value used in any DATE-TIME properties in
279 all components, unless [RFC7809] is in effect.
281 When used to publish available time, the "ORGANIZER" property
282 specifies the calendar user associated with the published
283 available time.
285 If the "PRIORITY" property is specified in "VAVAILABILITY"
286 components, it is used to determine how that component is combined
287 with other "VAVAILABILITY" components. See Section 4.
289 Other calendar properties MAY be specified in "VAVAILABILITY" or
290 "AVAILABLE" components and are considered attributes of the marked
291 block of time. Their usage is application specific. For example,
292 the "LOCATION" property might be used to indicate that a person is
293 available in one location for part of the week and a different
294 location for another part of the week (but see Section 9 for when
295 it is appropriate to add additional data like this).
297 Example: The following is an example of a "VAVAILABILITY" calendar
298 component used to represent the availability of a user, always
299 available Monday through Friday, 9:00 AM to 5:00 PM in the
300 America/Montreal time zone:
302 BEGIN:VAVAILABILITY
303 ORGANIZER:mailto:bernard@example.com
304 UID:0428C7D2-688E-4D2E-AC52-CD112E2469DF
305 DTSTAMP:20111005T133225Z
306 BEGIN:AVAILABLE
307 UID:34EDA59B-6BB1-4E94-A66C-64999089C0AF
308 SUMMARY:Monday to Friday from 9:00 to 17:00
309 DTSTART;TZID=America/Montreal:20111002T090000
310 DTEND;TZID=America/Montreal:20111002T170000
311 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
312 END:AVAILABLE
313 END:VAVAILABILITY
315 The following is an example of a "VAVAILABILITY" calendar
316 component used to represent the availability of a user available
317 Monday through Thursday, 9:00 AM to 5:00 PM at the main office,
318 and Friday 9:00 AM to 12:00 PM in the branch office in the
319 America/Montreal time zone between October 2nd and December 2nd
320 2011:
322 BEGIN:VAVAILABILITY
323 ORGANIZER:mailto:bernard@example.com
324 UID:84D0F948-7FC6-4C1D-BBF3-BA9827B424B5
325 DTSTAMP:20111005T133225Z
326 DTSTART;TZID=America/Montreal:20111002T000000
327 DTEND;TZID=America/Montreal:20111202T000000
328 BEGIN:AVAILABLE
329 UID:7B33093A-7F98-4EED-B381-A5652530F04D
330 SUMMARY:Monday to Thursday from 9:00 to 17:00
331 DTSTART;TZID=America/Montreal:20111002T090000
332 DTEND;TZID=America/Montreal:20111002T170000
333 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH
334 LOCATION:Main Office
335 END:AVAILABLE
336 BEGIN:AVAILABLE
337 UID:DF39DC9E-D8C3-492F-9101-0434E8FC1896
338 SUMMARY:Friday from 9:00 to 12:00
339 DTSTART;TZID=America/Montreal:20111006T090000
340 DTEND;TZID=America/Montreal:20111006T120000
341 RRULE:FREQ=WEEKLY
342 LOCATION:Branch Office
343 END:AVAILABLE
344 END:VAVAILABILITY
346 The following is an example of three "VAVAILABILITY" calendar
347 components used to represent the availability of a traveling
348 worker: Monday through Friday, 9:00 AM to 5:00 PM each day.
349 However, for three weeks the calendar user is working in Montreal,
350 then one week in Denver, then back to Montreal. Note that each
351 overall period is covered by separate "VAVAILABILITY" components.
352 The last of these has no DTEND so continues on "for ever". This
353 example shows one way "blocks" of available time can be
354 represented. See Section 4 for another approach using priorities.
356 BEGIN:VAVAILABILITY
357 ORGANIZER:mailto:bernard@example.com
358 UID:BE082249-7BDD-4FE0-BDBA-DE6598C32FC9
359 DTSTAMP:20111005T133225Z
360 DTSTART;TZID=America/Montreal:20111002T000000
361 DTEND;TZID=America/Montreal:20111023T030000
362 BEGIN:AVAILABLE
363 UID:54602321-CEDB-4620-9099-757583263981
364 SUMMARY:Monday to Friday from 9:00 to 17:00
365 DTSTART;TZID=America/Montreal:20111002T090000
366 DTEND;TZID=America/Montreal:20111002T170000
367 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
368 LOCATION:Montreal
369 END:AVAILABLE
370 END:VAVAILABILITY
371 BEGIN:VAVAILABILITY
372 ORGANIZER:mailto:bernard@example.com
373 UID:A1FF55E3-555C-433A-8548-BF4864B5621E
374 DTSTAMP:20111005T133225Z
375 DTSTART;TZID=America/Denver:20111023T000000
376 DTEND;TZID=America/Denver:20111030T000000
377 BEGIN:AVAILABLE
378 UID:57DD4AAF-3835-46B5-8A39-B3B253157F01
379 SUMMARY:Monday to Friday from 9:00 to 17:00
380 DTSTART;TZID=America/Denver:20111023T090000
381 DTEND;TZID=America/Denver:20111023T170000
382 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
383 LOCATION:Denver
384 END:AVAILABLE
385 END:VAVAILABILITY
386 BEGIN:VAVAILABILITY
387 ORGANIZER:mailto:bernard@example.com
388 UID:1852F9E1-E0AA-4572-B4C4-ED1680A4DA40
389 DTSTAMP:20111005T133225Z
390 DTSTART;TZID=America/Montreal:20111030T030000
391 BEGIN:AVAILABLE
392 UID:D27C421F-16C2-4ECB-8352-C45CA352C72A
393 SUMMARY:Monday to Friday from 9:00 to 17:00
394 DTSTART;TZID=America/Montreal:20111030T090000
395 DTEND;TZID=America/Montreal:20111030T170000
396 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
397 LOCATION:Montreal
398 END:AVAILABLE
399 END:VAVAILABILITY
401 3.2. Busy Time Type
403 Property Name: BUSYTYPE
405 Purpose: This property specifies the default busy time type.
407 Value Type: TEXT
409 Property Parameters: IANA and non-standard property parameters can
410 be specified on this property.
412 Conformance: This property can be specified within "VAVAILABILITY"
413 calendar components.
415 Format Definition: This property is defined by the following
416 notation:
418 busytype = "BUSYTYPE" busytypeparam ":" busytypevalue CRLF
420 busytypeparam = *(";" other-param)
422 busytypevalue = "BUSY" / "BUSY-UNAVAILABLE" /
423 "BUSY-TENTATIVE" / iana-token / x-name
424 ; Default is "BUSY-UNAVAILABLE".
426 Description: This property is used to specify the default busy time
427 type. The values correspond to those used by the "FBTYPE"
428 parameter used on a "FREEBUSY" property, with the exception that
429 the "FREE" value is not used in this property. If not specified
430 on a component that allows this property, the default is "BUSY-
431 UNAVAILABLE".
433 Example: The following is an example of this property:
435 BUSYTYPE:BUSY
437 4. Combining VAVAILABILITY components
439 The "VAVAILABILITY" component allows a calendar user to describe
440 their availability over extended periods of time through the use of
441 recurrence patterns. This availability might be relatively constant
442 from year to year.
444 However, there is usually some degree of irregularity, as people take
445 vacations or perhaps spend a few weeks at a different office. For
446 that period of time there is a need to redefine their availability.
448 Rather than modify their existing availability, the "PRIORITY"
449 property allows new "VAVAILABILITY" components to override others of
450 lower ordinal priority. Note that iCalendar [RFC5545] defines the
451 "PRIORITY" property such that a value of 0 is undefined, 1 is the
452 highest priority and 9 is the lowest.
454 When combining "VAVAILABILITY" components, an absence of a "PRIORITY"
455 property or a value of 0 implies the lowest level of priority. When
456 two or more VAVAILABILITY components overlap, and they have the same
457 PRIORITY value, the overlapping busy time type is determined by the
458 following order: BUSY > BUSY-UNAVAILABLE > BUSY-TENTATIVE. i.e., if
459 one component has a BUSYTYPE set to BUSY, and the another has
460 BUSYTYPE set to BUSY-UNAVAILABLE, then the effective busy time type
461 over the time range that they overlap would be BUSY. It is up to the
462 creator of such components to ensure that combining them produces a
463 consistent and expected result.
465 To calculate the available time, order the intersecting
466 "VAVAILABILITY" components by priority (i.e., lowest to highest
467 "PRIORITY" values are 0, 9, 8, 7, 6, 5, 4, 3, 2, 1).
469 Step through the resulting list of "VAVAILABILITY" components. For
470 each, the time range covered by the "VAVAILABILITY" component is set
471 to busy and then portions of it defined by the "AVAILABLE" components
472 in the "VAVAILABILITY" component are set to free.
474 Note that, if any "VAVAILABILITY" component completely covers the
475 date range of interest, then any lower priority "VAVAILABILITY"
476 components can be ignored.
478 Typically, a calendar user's "default" availability (e.g., business
479 hours of Monday through Friday, 9:00 am to 5:00 pm) would use the
480 lowest level of priority: zero. Any overrides to the "default" would
481 use higher levels as needed. To avoid having to keep readjusting the
482 "PRIORITY" property value when an override has to be "inserted"
483 between two existing components, priority values SHOULD be "spaced
484 out" over the full range of values. The table below illustrates this
485 via an example. The first row shows the priority range from low to
486 high, the second row shows the corresponding "PRIORITY" property
487 value, and the third row shows which "VAVAILABILITY" component has
488 that priority. The "default" availability is created with priority
489 zero (shown as {a} in the table), then the first override created
490 with priority 5 (shown as {b} in the table), a subsequent
491 availability can be inserted between the two by using priority 7
492 (shown as {c} in the table), and another, taking precedence over all
493 existing ones, with priority 3 (shown as {d} in the table). As seen
494 in the table, additional "slots" are open for more "VAVAILABILITY"
495 components to be added with other priorities if needed.
497 +-----+----+----+-----+----+-----+----+-----+----+------+
498 | Low | | | | | | | | | High |
499 +-----+----+----+-----+----+-----+----+-----+----+------+
500 | 0 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
501 +-----+----+----+-----+----+-----+----+-----+----+------+
502 | {a} | | | {c} | | {b} | | {d} | | |
503 +-----+----+----+-----+----+-----+----+-----+----+------+
505 5. Calculating Free-Busy Time
507 This section describes how free-busy time information for a calendar
508 user is calculated in the presence of "VAVAILABILITY" calendar
509 components.
511 An iCalendar "VFREEBUSY" component is used to convey "rolled-up"
512 free-busy time information for a calendar user. This can be
513 generated as the result of an iTIP free-busy [RFC5546] request or
514 through some other mechanism (e.g., a CalDAV calendar-access
515 CALDAV:free-busy-query REPORT).
517 When one or more "VAVAILABILITY" components are present and intersect
518 the time-range for the free-busy request, first the available time is
519 calculated, as outlined in Section 4. Once that is done, regular
520 "VEVENT" and "VFREEBUSY" components can be "overlaid" in the usual
521 way to block out time.
523 An example procedure for this is as follows:
525 1. Initially mark the entire period of the free-busy request as
526 free.
528 2. For each "VAVAILABILITY" component ordered by PRIORITY (lowest to
529 highest):
531 A. Determine if the "VAVAILABILITY" intersects the time-range of
532 the free-busy request. If not ignore it.
534 B. Determine if the "VAVAILABILITY" is completely overridden by
535 a higher priority component. If so ignore it.
537 C. For the time period covered by the "VAVAILABILITY" component,
538 mark time in the free-busy request result set as busy, using
539 the busy time type derived from the "BUSYTYPE" property in
540 the "VAVAILABILITY" component.
542 D. Append the "VAVAILABILITY" component to a list of components
543 for further processing in step 3, if it has not been ignored.
545 3. For each "VAVAILABILITY" component in the list resulting from
546 step 2, in order from the first item to the last item:
548 A. For each "AVAILABLE" component in the "VAVAILABILITY"
549 component:
551 i. Expand all recurring instances, taking into account
552 overridden instances, ignoring instances or parts of
553 instances that fall outside of the free-busy request time-
554 range or the time period specified by the "VAVAILABILITY"
555 component.
557 ii. For each instance, mark the corresponding time in the
558 free-busy request result set as free.
560 4. For each "VEVENT" or "VFREEBUSY" component apply normal free-busy
561 processing within the free-busy request time-range.
563 5.1. Examples
565 In the examples below a table is used to represent time slots for the
566 period of a free-busy request. Each time slot is two hours long.
567 The column header represents the hours from midnight local time.
568 Each row below the column headers represents a step in the free-busy
569 result set determination, following the procedure outlined above.
571 Each cell in the rows below the column header contains a single
572 character that represents the free-busy type for the corresponding
573 time period at the end of the process step represented by the row.
574 The characters in the row are:
576 F Represents "FREE" time in that slot.
578 B Represents "BUSY" time in that slot.
580 U Represents "BUSY-UNAVAILABLE" time in that slot.
582 T Represents "BUSY-TENTATIVE" time in that slot.
584 I Represents data to be ignored in that slot (as per step 2.B
585 above).
587 5.1.1. Simple Example
589 Appendix A shows the user's calendar. This includes one
590 "VAVAILABILITY" component giving available time within the requested
591 time-range of 8:00 AM to 6:00 PM, together with one "VEVENT"
592 component representing a two hour meeting starting at 12:00 PM.
594 A free-busy request for Monday, 6th November 2011, midnight to
595 midnight in the America/Montreal timezone would be calculated as
596 follows using the steps described above.
598 +------+----+----+----+----+----+----+----+----+----+----+----+----+
599 | Step | 0 | 2 | 4 | 6 | 8 | 10 | 12 | 14 | 16 | 18 | 20 | 22 |
600 +------+----+----+----+----+----+----+----+----+----+----+----+----+
601 | 1. | F | F | F | F | F | F | F | F | F | F | F | F |
602 | 2. | U | U | U | U | U | U | U | U | U | U | U | U |
603 | 3. | U | U | U | U | F | F | F | F | F | U | U | U |
604 | 4. | U | U | U | U | F | F | B | F | F | U | U | U |
605 +------+----+----+----+----+----+----+----+----+----+----+----+----+
607 5.1.2. Further Example
609 Appendix B shows another way to represent the availability of the
610 traveling worker shown above. Here we represent their base
611 availability of Monday through Friday, 8:00 AM to 6:00 PM each day
612 with a "VAVAILABILITY" with default "PRIORITY" (there is no "DTEND"
613 property so that this availability is unbounded). For the week the
614 calendar user is working in Denver (October 23rd through October
615 30th), we represent their availability with a "VAVAILABILITY"
616 component with priority 1, which overrides the base availability.
617 There is also a two hour meeting starting at 12:00 PM (in the
618 America/Denver time zone).
620 A free-busy request for Monday, 24th October 2011, midnight to
621 midnight in the America/Montreal timezone, would be calculated as
622 follows using the steps described above. Note that there is a two
623 hour offset in the in the available time, compared to the previous
624 example, due to the two hour difference between the time zone of the
625 free busy request and the time zone of the user's availability and
626 meeting. "2.P0" shows the base availability, and "2.P1" shows the
627 higher priority availability. "3.P1" only shows the higher priority
628 availability contributing to the overall free busy, since the default
629 availability is ignored (as per step 2.B described above).
631 +------+----+----+----+----+----+----+----+----+----+----+----+----+
632 | Step | 0 | 2 | 4 | 6 | 8 | 10 | 12 | 14 | 16 | 18 | 20 | 22 |
633 +------+----+----+----+----+----+----+----+----+----+----+----+----+
634 | 1. | F | F | F | F | F | F | F | F | F | F | F | F |
635 | 2.P0 | I | I | I | I | I | I | I | I | I | I | I | I |
636 | 2.P1 | U | U | U | U | U | U | U | U | U | U | U | U |
637 | 3.P1 | U | U | U | U | U | F | F | F | F | F | U | U |
638 | 4. | U | U | U | U | U | F | F | B | F | F | U | U |
639 +------+----+----+----+----+----+----+----+----+----+----+----+----+
641 6. Use with iTIP
643 This specification does not define how "VAVAILABILITY" components are
644 used in scheduling messages sent using the iTIP [RFC5546] protocol.
645 It is expected that future specifications will define how iTIP
646 scheduling can make use of "VAVAILABILITY" components.
648 7. CalDAV Extensions
650 7.1. CalDAV Requirements Overview
652 This section lists what functionality is required of a CalDAV server
653 which supports "VAVAILABILITY" components in stored calendar data. A
654 server:
656 o MUST advertise support for "VAVAILABILITY" components in
657 CALDAV:supported-calendar-component-set properties on calendars
658 which allow storing of such components;
660 o MUST support CALDAV:free-busy-query REPORTs that aggregate the
661 information in any "VAVAILABILITY" components in the calendar
662 collections targeted by the request;
664 o MUST support "VAVAILABILITY" components stored in a
665 CALDAV:calendar-availability WebDAV property on a CalDAV
666 scheduling inbox collection, if the CalDAV calendar-auto-schedule
667 feature is supported;
669 o MUST support iTIP [RFC5546] free-busy requests that aggregate the
670 information in any "VAVAILABILITY" components in calendar
671 collections that contribute to free-busy, or in any
672 "VAVAILABILITY" components stored in the CALDAV:calendar-
673 availability property on the CalDAV scheduling inbox collection of
674 the calendar user targeted by the iTIP free-busy request, if the
675 CalDAV calendar-auto-schedule feature is available.
677 Processing of "VAVAILABILITY" components MUST conform to all the
678 requirements CalDAV imposes on calendar object resources (see
679 Section 4.1 of [RFC4791]).
681 7.2. New features in CalDAV
683 7.2.1. Calendar Availability Support
685 A server supporting the features described in this document MUST
686 include "calendar-availability" as a field in the DAV response header
687 from an OPTIONS request. A value of "calendar-availability" in the
688 DAV response header indicates to clients that the server supports all
689 the requirements specified in this document.
691 7.2.1.1. Example: Using OPTIONS for the Discovery of Calendar
692 Availability Support
694 >> Request <<
696 OPTIONS /home/bernard/calendars/ HTTP/1.1
697 Host: cal.example.com
699 >> Response <<
701 HTTP/1.1 200 OK
702 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
703 Allow: PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL
704 DAV: 1, 2, 3, access-control, calendar-access,
705 calendar-availability
706 Date: Fri, 11 Nov 2005 09:32:12 GMT
707 Content-Length: 0
709 In this example, the OPTIONS method returns the value "calendar-
710 availability" in the DAV response header to indicate that the
711 collection "/home/bernard/calendars/" supports the new features
712 defined in this specification.
714 7.2.2. CalDAV Time Range Queries
716 Section 9.9 of [RFC4791] describes how to specify time ranges to
717 limit the set of calendar components returned by the server. This
718 specification extends [RFC4791] to describe how to apply time range
719 filtering to "VAVAILABILITY" components.
721 A "VAVAILABILITY" component is said to overlap a given time range if
722 the condition for the corresponding component state specified in the
723 table below is satisfied. The conditions depend on the presence of
724 the "DTSTART", "DTEND", and "DURATION" properties in the
725 "VAVAILABILITY" component. Note that, as specified above, the
726 "DTEND" value MUST be a "DATE-TIME" value equal to or after the
727 "DTSTART" value, if specified.
729 +------------------------------------------------------------+
730 | VAVAILABILITY has the DTSTART property? |
731 | +--------------------------------------------------------+
732 | | VAVAILABILITY has the DTEND property? |
733 | | +----------------------------------------------------+
734 | | | VAVAILABILITY has the DURATION property? |
735 | | | +------------------------------------------------+
736 | | | | Condition to evaluate |
737 +---+---+---+------------------------------------------------+
738 | Y | Y | N | (start < DTEND AND end > DTSTART) |
739 +---+---+---+------------------------------------------------+
740 | Y | N | Y | (start < DTSTART+DURATION AND end > DTSTART) |
741 +---+---+---+------------------------------------------------+
742 | Y | N | N | (end > DTSTART) |
743 +---+---+---+------------------------------------------------+
744 | N | Y | N | (start < DTEND) |
745 +---+---+---+------------------------------------------------+
746 | N | N | * | TRUE |
747 +---+---+---+------------------------------------------------+
749 7.2.3. CALDAV:free-busy-query REPORT
751 A CALDAV:free-busy-query REPORT can be executed on a calendar
752 collection that contains iCalendar "VAVAILABILITY" components. When
753 that occurs, the server MUST aggregate the information in any
754 "VAVAILABILITY" components when generating the free-busy response, as
755 described in Section 5.
757 7.2.4. CALDAV:calendar-availability Property
759 Name: calendar-availability
761 Namespace: urn:ietf:params:xml:ns:caldav
763 Purpose: Defines a "VAVAILABILITY" component that will be used in
764 calculating free-busy time when an iTIP free-busy request is
765 targeted at the calendar user who owns the Inbox.
767 Conformance: This property MAY be protected and SHOULD NOT be
768 returned by a PROPFIND DAV:allprop request. Support for this
769 property is REQUIRED. The value of this property MUST be a valid
770 iCalendar object containing only one "VAVAILABILITY" component,
771 and optionally, "VTIMEZONE" components - other iCalendar
772 components MUST NOT be present. "VTIMEZONE" components SHOULD NOT
773 be present if [RFC7809] is in effect. For more complex
774 availability scenarios, clients can store multiple "VAVAILABILITY"
775 components in the calendar user's calendar collections.
777 Description: This property allows a user to specify their
778 availability by including an "VAVAILABILITY" component in the
779 value of this property. If present, the server MUST use this
780 "VAVAILABILITY" component when determining free-busy information
781 as part of an iTIP free-busy request being handled by the server.
783 Definition:
785
786 ; Data value MUST be iCalendar object containing
787 ; "VAVAILABILITY" or "VTIMEZONE" components.
789 Example:
791 BEGIN:VCALENDAR
794 CALSCALE:GREGORIAN
795 PRODID:-//example.com//iCalendar 2.0//EN
796 VERSION:2.0
797 BEGIN:VAVAILABILITY
798 UID:9BADC1F6-0FC4-44BF-AC3D-993BEC8C962A
799 DTSTAMP:20111005T133225Z
800 DTSTART;TZID=America/Montreal:20111002T000000
801 BEGIN:AVAILABLE
802 UID:6C9F69C3-BDA8-424E-B2CB-7012E796DDF7
803 SUMMARY:Monday to Friday from 9:00 to 18:00
804 DTSTART;TZID=America/Montreal:20111002T090000
805 DTEND;TZID=America/Montreal:20111002T180000
806 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
807 END:AVAILABLE
808 END:VAVAILABILITY
809 END:VCALENDAR
810
812 7.2.5. iTIP free-busy requests
814 The [RFC6638] processing of an iTIP free-busy request targeted at the
815 owner of the CALDAV:schedule-inbox will include free-busy information
816 derived from "VAVAILABILITY" components in any calendar collection
817 targeted during the request, as described in Section 5. In addition,
818 the "VAVAILABILITY" component specified in the CALDAV:calendar-
819 availability property on the owner's Inbox, MUST be included in the
820 free-busy calculation.
822 8. Security Considerations
824 Calculation of availability information, particularly with multiple
825 overlapping time-ranges, can be complex, and CalDAV servers MUST
826 limit the complexity of such data stored by a client.
828 An attacker able to "inject" availability information into a calendar
829 user's calendar data could ensure that the user never appears free
830 for meetings, or appears free at inappropriate times. Calendar
831 systems MUST ensure that availability information for a calendar user
832 can only be modified by authorized users.
834 Security considerations in [RFC5545], [RFC5546], [RFC4791],
835 [RFC6638], and [RFC7809] MUST also be adhered to.
837 9. Privacy Considerations
839 Free-busy and availability information can be used by attackers to
840 infer the whereabouts or overall level of "activity" of the
841 corresponding calendar user. Any calendar system that allows a user
842 to expose their free-busy and availability information MUST limit
843 access to that information to only authorized users.
845 When "VAVAILABILITY" components are sent to or shared with other
846 calendar users, care has to be taken not to expose more information
847 than is needed by each recipient. For example, a business owner will
848 likely not want their customers to know where they might be or what
849 they might be doing, but family members might be willing to expose
850 such information to each other. Thus, calendaring systems allowing
851 "VAVAILABILITY" components to be sent or shared to other calendar
852 users, MUST provide a way for non-essential properties to be removed
853 (e.g., "SUMMARY", "LOCATION", and "DESCRIPTION").
855 iCalendar "VFREEBUSY" information generated from "VAVAILABILITY"
856 components MUST NOT include information other than busy or free time
857 periods. In particular, user specified property values such as
858 "SUMMARY", "LOCATION" and "DESCRIPTION" MUST NOT be copied into the
859 free-busy result data.
861 Privacy considerations in [RFC5545], [RFC5546], [RFC4791], [RFC6638],
862 and [RFC7809] MUST also be adhered to.
864 10. IANA Considerations
865 10.1. Component Registrations
867 This documents defines the following new iCalendar components to be
868 added to the registry defined in Section 8.3.1 of [RFC5545]:
870 +---------------+---------+-----------------------+
871 | Component | Status | Reference |
872 +---------------+---------+-----------------------+
873 | VAVAILABILITY | Current | RFCXXXX, Section 3.1 |
874 | AVAILABLE | Current | RFCXXXX, Section 3.1 |
875 +---------------+---------+-----------------------+
877 10.2. Property Registrations
879 This documents defines the following new iCalendar properties to be
880 added to the registry defined in Section 8.3.2 of [RFC5545]:
882 +----------+---------+-----------------------+
883 | Property | Status | Reference |
884 +----------+---------+-----------------------+
885 | BUSYTYPE | Current | RFCXXXX, Section 3.2 |
886 +----------+---------+-----------------------+
888 11. Acknowledgments
890 Thanks to the following for providing feedback: Toby Considine
891 Bernard Desruisseaux, Alexey Melnikov, Daniel Migault, Ken Murchison,
892 Evert Pot, Dave Thewlis. This specification came about via
893 discussions at the Calendaring and Scheduling Consortium.
895 12. Normative References
897 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
898 Requirement Levels", BCP 14, RFC 2119,
899 DOI 10.17487/RFC2119, March 1997,
900 .
902 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
903 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
904 DOI 10.17487/RFC4791, March 2007,
905 .
907 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
908 Scheduling Core Object Specification (iCalendar)",
909 RFC 5545, DOI 10.17487/RFC5545, September 2009,
910 .
912 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
913 Interoperability Protocol (iTIP)", RFC 5546,
914 DOI 10.17487/RFC5546, December 2009,
915 .
917 [RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to
918 CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012,
919 .
921 [RFC7809] Daboo, C., "Calendaring Extensions to WebDAV (CalDAV):
922 Time Zones by Reference", RFC 7809, DOI 10.17487/RFC7809,
923 March 2016, .
925 Appendix A. Example Calendar #1
927 BEGIN:VCALENDAR
928 CALSCALE:GREGORIAN
929 PRODID:-//example.com//iCalendar 2.0//EN
930 VERSION:2.0
931 BEGIN:VEVENT
932 DTSTAMP:20111113T044111Z
933 DTSTART;TZID=America/Montreal:20111106T120000
934 DURATION:PT2H
935 SUMMARY:Meeting
936 UID:768CB0C2-8642-43F7-A6C4-F8BB04B829B4
937 END:VEVENT
938 BEGIN:VAVAILABILITY
939 UID:452DFCA7-3203-4A3D-9A9A-99753A383B41
940 DTSTAMP:20111005T133225Z
941 DTSTART;TZID=America/Montreal:20111002T000000
942 BEGIN:AVAILABLE
943 UID:466D5C68-5C4A-4078-AF5D-9C55EA9145D7
944 SUMMARY:Monday to Friday from 8:00 to 18:00
945 DTSTART;TZID=America/Montreal:20111002T080000
946 DTEND;TZID=America/Montreal:20111002T180000
947 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
948 END:AVAILABLE
949 END:VAVAILABILITY
950 END:VCALENDAR
952 Appendix B. Example Calendar #2
953 BEGIN:VCALENDAR
954 CALSCALE:GREGORIAN
955 PRODID:-//example.com//iCalendar 2.0//EN
956 VERSION:2.0
957 BEGIN:VEVENT
958 DTSTAMP:20111113T044111Z
959 DTSTART;TZID=America/Denver:20111106T120000
960 DURATION:PT2H
961 SUMMARY:Lunch meeting in Denver
962 UID:2346C09A-42BF-439E-916C-FC83AF869171
963 END:VEVENT
964 BEGIN:VAVAILABILITY
965 ORGANIZER:mailto:bernard@example.com
966 UID:627A87FA-E5F1-43C0-B3B1-567DA10F2A83
967 DTSTAMP:20111005T133225Z
968 DTSTART;TZID=America/Montreal:20111002T000000
969 BEGIN:AVAILABLE
970 UID:A833E850-892B-43F6-98B6-C15A6BFC5D27
971 SUMMARY:Monday to Friday from 9:00 to 17:00
972 DTSTART;TZID=America/Montreal:20111002T080000
973 DTEND;TZID=America/Montreal:20111002T180000
974 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
975 LOCATION:Montreal
976 END:AVAILABLE
977 END:VAVAILABILITY
978 BEGIN:VAVAILABILITY
979 ORGANIZER:mailto:bernard@example.com
980 UID:F01411E3-38B8-4490-8A1F-0CCEC57A0943
981 DTSTAMP:20111005T133225Z
982 DTSTART;TZID=America/Denver:20111023T000000
983 DTEND;TZID=America/Denver:20111030T000000
984 PRIORITY:1
985 BEGIN:AVAILABLE
986 UID:A35AA091-3846-48ED-96F6-881E8A0D0A93
987 SUMMARY:Monday to Friday from 9:00 to 17:00
988 DTSTART;TZID=America/Denver:20111023T080000
989 DTEND;TZID=America/Denver:20111023T180000
990 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
991 LOCATION:Denver
992 END:AVAILABLE
993 END:VAVAILABILITY
994 END:VCALENDAR
996 Appendix C. Change History (To be removed by RFC Editor before
997 publication)
999 Changes in draft-ietf-calext-availability-04:
1001 1. [OPSDIR] Mark as updating 5545, 4791, 6638.
1003 2. [OPSDIR] Moved alternative example to Appendix.
1005 3. [OPSDIR] Use different symbols for different nested list levels
1006 in Section 5.
1008 4. [OPSDIR] Added table to illustrate spacing out priority values.
1010 5. [OPSDIR] Editorial fixes.
1012 6. [IESG] changed to MUST for server applying limits.
1014 7. [IESG] Editorial fixes.
1016 8. Changed UID values to UUIDs.
1018 9. Abstract tweak to spell out CalDAV.
1020 Changes in draft-ietf-calext-availability-03:
1022 1. [EXPERT] Make 7809 reference more authoritative.
1024 2. [EXPERT] Add reference to privacy section when describing use of
1025 LOCATION.
1027 3. [EXPERT] Added more text to privacy section to cover published
1028 or iTIP-messaged VAVAILABILITY components.
1030 4. [EXPERT] Clarify highest to lowest priority ordering in free-
1031 busy calculation.
1033 5. [EXPERT] Fixed PRIORITY in example.
1035 6. [EXPERT] Editorial fixes.
1037 7. [EXPERT] Clarify that calendar-availability follows the RFC7809
1038 rule wrt VTIMEZONE presence.
1040 8. [WGCHAIR] Added text suggesting how best to assign priority
1041 values.
1043 9. [WGCHAIR] Clarify example procedure step 3 ordering.
1045 10. Be more explicit about dependent security and privacy
1046 considerations.
1048 Changes in draft-ietf-calext-availability-02:
1050 1. [WGLC] Change Appendix A example to start available time at
1051 08:00.
1053 2. [WGLC] Added new section with table describing CalDAV time range
1054 query behavior.
1056 3. Added text and reference to RFC7809.
1058 4. Added location to formal syntax of components.
1060 Changes in draft-ietf-calext-availability-01:
1062 1. Minor editorial fixes.
1064 2. ABNF syntax fixes.
1066 3. Clarify BUSTYPE precedence when combining components with the
1067 same PRIORITY values.
1069 4. Added section explaining that iTIP use is not defined
1071 5. Added Privacy Considerations and tweaked Security Considerations.
1073 6. Added diagram to illustrate the overall concept.
1075 7. Limit the calendar-availability property to a single
1076 "VAVAILABILITY" component.
1078 Changes in draft-ietf-calext-availability-00:
1080 1. Re-publication as WG document.
1082 Changes in draft-daboo-calendar-availability-05:
1084 1. Small typos.
1086 2. Fix explanation of priority.
1088 3. Change uid values to make legal and easier to follow.
1090 Changes in draft-daboo-calendar-availability-04:
1092 1. Small typos.
1094 2. Add prioritized example.
1096 Changes in draft-daboo-calendar-availability-03:
1098 1. Switch authors.
1100 2. CalDAV scheduling is now rfc6638.
1102 3. List priority as a vavailability property and define its use.
1104 Changes in draft-daboo-calendar-availability-02:
1106 1. Updated to 5545/5546 references.
1108 2. Fixed some examples.
1110 3. Added some more properties to the components
1112 4. Fixed text that said dtstart was required in VAVAILABILITY
1114 Changes in draft-daboo-calendar-availability-01:
1116 1. Allow property on Inbox for caldav-schedule.
1118 2. Clarify that DURATION can only be present in VAVAILABILITY if
1119 DTSTART is also present, and DTEND is not.
1121 3. Updated references.
1123 4. Added templates.
1125 Authors' Addresses
1127 Cyrus Daboo
1128 Apple Inc.
1129 1 Infinite Loop
1130 Cupertino, CA 95014
1131 USA
1133 Email: cyrus@daboo.name
1134 URI: http://www.apple.com/
1135 Michael Douglass
1136 Spherical Cow Group
1137 226 3rd Street
1138 Troy, NY 12180
1139 USA
1141 Email: mdouglass@sphericalcowgroup.com
1142 URI: http://sphericalcowgroup.com