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