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