diff options
Diffstat (limited to 'doc/rfc/rfc7953.txt')
| -rw-r--r-- | doc/rfc/rfc7953.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc7953.txt b/doc/rfc/rfc7953.txt new file mode 100644 index 0000000..6348c23 --- /dev/null +++ b/doc/rfc/rfc7953.txt @@ -0,0 +1,1347 @@ + + + + + + +Internet Engineering Task Force (IETF) C. Daboo +Request for Comments: 7953 Apple +Updates: 4791, 5545, 6638 M. Douglass +Category: Standards Track Spherical Cow Group +ISSN: 2070-1721 August 2016 + + + Calendar Availability + +Abstract + + This document specifies a new iCalendar (RFC 5545) component that + allows the publication of available and unavailable time periods + associated with a calendar user. This component can be used in + standard iCalendar free-busy lookups, including the iCalendar + Transport-independent Interoperability Protocol (iTIP; RFC 5546) + free-busy requests, to generate repeating blocks of available or busy + time with exceptions as needed. + + This document also defines extensions to the Calendaring Extensions + to WebDAV (CalDAV) calendar access protocol (RFC 4791) and the + associated scheduling protocol (RFC 6638) to specify how this new + calendar component can be used when evaluating free-busy time. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7953. + + + + + + + + + + + + + + +Daboo & Douglass Standards Track [Page 1] + +RFC 7953 Calendar Availability August 2016 + + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 + 3. iCalendar Extensions . . . . . . . . . . . . . . . . . . . . 4 + 3.1. VAVAILABILITY Component . . . . . . . . . . . . . . . . . 4 + 3.2. Busy Time Type . . . . . . . . . . . . . . . . . . . . . 10 + 4. Combining VAVAILABILITY Components . . . . . . . . . . . . . 10 + 5. Calculating Free-Busy Time . . . . . . . . . . . . . . . . . 12 + 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 13 + 6. Use with iTIP . . . . . . . . . . . . . . . . . . . . . . . . 15 + 7. CalDAV Extensions . . . . . . . . . . . . . . . . . . . . . . 15 + 7.1. CalDAV Requirements Overview . . . . . . . . . . . . . . 15 + 7.2. New Features in CalDAV . . . . . . . . . . . . . . . . . 16 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 10.1. Component Registrations . . . . . . . . . . . . . . . . 20 + 10.2. Property Registrations . . . . . . . . . . . . . . . . . 20 + 11. Normative References . . . . . . . . . . . . . . . . . . . . 20 + Appendix A. Example Calendar #1 . . . . . . . . . . . . . . . . 22 + Appendix B. Example Calendar #2 . . . . . . . . . . . . . . . . 23 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 + + + + + + + + + + + + +Daboo & Douglass Standards Track [Page 2] + +RFC 7953 Calendar Availability August 2016 + + +1. Introduction + + Calendar users often have regular periods of time when they are + either available to be scheduled or always unavailable. For example, + an office worker will often wish only to appear free to their work + colleagues during normal 'office hours' (e.g., Monday through Friday, + 9 am through 5 pm). Or, a university professor might only be + available to students during a set period of time (e.g., Thursday + afternoons, 2 pm through 5 pm during term time only). Ideally, users + ought be able to specify such periods directly via their calendar + user agent and have them automatically considered as part of the + normal free-busy lookup for that user. In addition, it ought be + possible to present different periods of available time depending on + which user is making the request. + + iCalendar [RFC5545] defines a "VFREEBUSY" component that can be used + to represent fixed busy time periods, but it does not provide a way + to specify a repeating period of available or unavailable time. + Since repeating patterns are often the case, "VFREEBUSY" components + are not sufficient to solve this problem. + + This specification defines a new type of iCalendar component that can + be used to publish user availability. + + CalDAV [RFC4791] provides a way for calendar users to access and + manage calendar data and exchange this data via scheduling + operations. As part of this, the CalDAV calendar-access [RFC4791] + feature provides a CALDAV:free-busy-query REPORT that returns free- + busy information for a calendar collection or hierarchy of calendar + collections. Also, the CalDAV calendar-auto-schedule [RFC6638] + feature allows free-busy information for a calendar user to be + determined. Both of these operations involve examining user + calendars for events that 'block time', with the blocked out periods + being returned in a "VFREEBUSY" component. + + This specification extends the CalDAV calendar-access and CalDAV + calendar-auto-schedule features to allow the new iCalendar + availability components to be stored and manipulated and to allow + free-busy lookups to use the information from any such components, if + present. + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + + + +Daboo & Douglass Standards Track [Page 3] + +RFC 7953 Calendar Availability August 2016 + + + When XML element types in the namespaces "DAV:" and + "urn:ietf:params:xml:ns:caldav" are referenced in this document + outside of the context of an XML fragment, the string "DAV:" and + "CALDAV:" will be prefixed to the element type names respectively. + +3. iCalendar Extensions + + This specification adds a new "VAVAILABILITY" calendar component to + iCalendar. The "VAVAILABILITY" component is itself a container for + new "AVAILABLE" subcomponents. + + The purpose of the "VAVAILABILITY" calendar component is to provide a + grouping of available time information over a specific range of time. + Within that, there are specific time ranges that are marked as + available via a set of "AVAILABLE" calendar subcomponents. Together + these can be used to specify available time that can repeat over set + periods of time, and which can vary over time. + + An illustration of how "VAVAILABILITY" and "AVAILABLE" components + work is shown below. + + Time Range + <=========================================================> + + +-------------------------------------------------+ + | VAVAILABILITY | + +-------------------------------------------------+ + +------------+ +------------+ + | AVAILABLE | | AVAILABLE | + +------------+ +------------+ + + <-> <-----> <-----------> Busy Time + + The overall time range is shown at the top. A "VAVAILABILITY" + component spans part of the range. The time range covered by the + "VAVAILABILITY" component is considered to be busy, except for the + ranges covered by the "AVAILABLE" components within the + "VAVAILABILITY" component. + +3.1. VAVAILABILITY Component + + Component Name: VAVAILABILITY + + Purpose: Provide a grouping of component properties and + subcomponents that describe the availability associated with a + calendar user. + + + + + +Daboo & Douglass Standards Track [Page 4] + +RFC 7953 Calendar Availability August 2016 + + + Format Definition: A "VAVAILABILITY" calendar component is defined + by the following notation: + + availabilityc = "BEGIN" ":" "VAVAILABILITY" CRLF + availabilityprop *availablec + "END" ":" "VAVAILABILITY" CRLF + + availabilityprop = *( + ; + ; the following are REQUIRED + ; but MUST NOT occur more than once + ; + dtstamp / uid + ; + ; the following are OPTIONAL + ; but MUST NOT occur more than once + ; + busytype / class / created / description / + dtstart / last-mod / location / organizer / + priority /seq / summary / url / + ; + ; Either 'dtend' or 'duration' MAY appear + ; in an 'availableprop', but 'dtend' and + ; 'duration' MUST NOT occur in the same + ; 'availabilityprop'. + ; 'duration' MUST NOT be present if + ; 'dtstart' is not present + ; + dtend / duration / + ; + ; the following are OPTIONAL + ; and MAY occur more than once + ; + categories / comment / contact / + x-prop / iana-prop + ; + ) + + availablec = "BEGIN" ":" "AVAILABLE" CRLF + availableprop + "END" ":" "AVAILABLE" CRLF + + + + + + + + + + +Daboo & Douglass Standards Track [Page 5] + +RFC 7953 Calendar Availability August 2016 + + + availableprop = *( + ; + ; the following are REQUIRED + ; but MUST NOT occur more than once + ; + dtstamp / dtstart / uid / + ; + ; Either 'dtend' or 'duration' MAY appear in + ; an 'availableprop', but 'dtend' and + ; 'duration' MUST NOT occur in the same + ; 'availableprop'. + ; + dtend / duration / + ; + ; the following are OPTIONAL + ; but MUST NOT occur more than once + ; + created / description / last-mod / + location / recurid / rrule / summary / + ; + ; the following are OPTIONAL + ; and MAY occur more than once + ; + categories / comment / contact / exdate / + rdate / x-prop / iana-prop + ; + ) + + Description: A "VAVAILABILITY" component indicates a period of time + within which availability information is provided. A + "VAVAILABILITY" component can specify a start time and an end time + or duration. If "DTSTART" is not present, then the start time is + unbounded. If "DTEND" or "DURATION" are not present, then the end + time is unbounded. Within the specified time period, availability + defaults to a free-busy type of "BUSY-UNAVAILABLE" (see + Section 3.2), except for any time periods corresponding to + "AVAILABLE" subcomponents. + + "AVAILABLE" subcomponents are used to indicate periods of free + time within the time range of the enclosing "VAVAILABILITY" + component. "AVAILABLE" subcomponents MAY include recurrence + properties to specify recurring periods of time, which can be + overridden using normal iCalendar recurrence behavior (i.e., use + of the "RECURRENCE-ID" property). + + + + + + + +Daboo & Douglass Standards Track [Page 6] + +RFC 7953 Calendar Availability August 2016 + + + If specified, the "DTSTART" and "DTEND" properties in + "VAVAILABILITY" components and "AVAILABLE" subcomponents MUST be + "DATE-TIME" values specified as either the date with UTC time or + the date with local time and a time zone reference. + + The iCalendar object containing the "VAVAILABILITY" component MUST + contain appropriate "VTIMEZONE" components corresponding to each + unique "TZID" parameter value used in any DATE-TIME properties in + all components, unless [RFC7809] is in effect. + + When used to publish available time, the "ORGANIZER" property + specifies the calendar user associated with the published + available time. + + If the "PRIORITY" property is specified in "VAVAILABILITY" + components, it is used to determine how that component is combined + with other "VAVAILABILITY" components. See Section 4. + + Other calendar properties MAY be specified in "VAVAILABILITY" or + "AVAILABLE" components and are considered attributes of the marked + block of time. Their usage is application specific. For example, + the "LOCATION" property might be used to indicate that a person is + available in one location for part of the week and a different + location for another part of the week (but see Section 9 for when + it is appropriate to add additional data like this). + + Example: The following is an example of a "VAVAILABILITY" calendar + component used to represent the availability of a user, always + available Monday through Friday, 9:00 am to 5:00 pm in the + America/Montreal time zone: + + BEGIN:VAVAILABILITY + ORGANIZER:mailto:bernard@example.com + UID:0428C7D2-688E-4D2E-AC52-CD112E2469DF + DTSTAMP:20111005T133225Z + BEGIN:AVAILABLE + UID:34EDA59B-6BB1-4E94-A66C-64999089C0AF + SUMMARY:Monday to Friday from 9:00 to 17:00 + DTSTART;TZID=America/Montreal:20111002T090000 + DTEND;TZID=America/Montreal:20111002T170000 + RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR + END:AVAILABLE + END:VAVAILABILITY + + + + + + + + +Daboo & Douglass Standards Track [Page 7] + +RFC 7953 Calendar Availability August 2016 + + + The following is an example of a "VAVAILABILITY" calendar + component used to represent the availability of a user available + Monday through Thursday, 9:00 am to 5:00 pm, at the main office, + and Friday, 9:00 am to 12:00 pm, in the branch office in the + America/Montreal time zone between October 2nd and December 2nd + 2011: + + BEGIN:VAVAILABILITY + ORGANIZER:mailto:bernard@example.com + UID:84D0F948-7FC6-4C1D-BBF3-BA9827B424B5 + DTSTAMP:20111005T133225Z + DTSTART;TZID=America/Montreal:20111002T000000 + DTEND;TZID=America/Montreal:20111202T000000 + BEGIN:AVAILABLE + UID:7B33093A-7F98-4EED-B381-A5652530F04D + SUMMARY:Monday to Thursday from 9:00 to 17:00 + DTSTART;TZID=America/Montreal:20111002T090000 + DTEND;TZID=America/Montreal:20111002T170000 + RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH + LOCATION:Main Office + END:AVAILABLE + BEGIN:AVAILABLE + UID:DF39DC9E-D8C3-492F-9101-0434E8FC1896 + SUMMARY:Friday from 9:00 to 12:00 + DTSTART;TZID=America/Montreal:20111006T090000 + DTEND;TZID=America/Montreal:20111006T120000 + RRULE:FREQ=WEEKLY + LOCATION:Branch Office + END:AVAILABLE + END:VAVAILABILITY + + The following is an example of three "VAVAILABILITY" calendar + components used to represent the availability of a traveling + worker: Monday through Friday, 9:00 am to 5:00 pm each day. + However, for three weeks the calendar user is working in Montreal, + then one week in Denver, then back to Montreal. Note that each + overall period is covered by separate "VAVAILABILITY" components. + The last of these has no DTEND so it continues on "forever". This + example shows one way "blocks" of available time can be + represented. See Section 4 for another approach using priorities. + + + + + + + + + + + +Daboo & Douglass Standards Track [Page 8] + +RFC 7953 Calendar Availability August 2016 + + + BEGIN:VAVAILABILITY + ORGANIZER:mailto:bernard@example.com + UID:BE082249-7BDD-4FE0-BDBA-DE6598C32FC9 + DTSTAMP:20111005T133225Z + DTSTART;TZID=America/Montreal:20111002T000000 + DTEND;TZID=America/Montreal:20111023T030000 + BEGIN:AVAILABLE + UID:54602321-CEDB-4620-9099-757583263981 + SUMMARY:Monday to Friday from 9:00 to 17:00 + DTSTART;TZID=America/Montreal:20111002T090000 + DTEND;TZID=America/Montreal:20111002T170000 + RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR + LOCATION:Montreal + END:AVAILABLE + END:VAVAILABILITY + BEGIN:VAVAILABILITY + ORGANIZER:mailto:bernard@example.com + UID:A1FF55E3-555C-433A-8548-BF4864B5621E + DTSTAMP:20111005T133225Z + DTSTART;TZID=America/Denver:20111023T000000 + DTEND;TZID=America/Denver:20111030T000000 + BEGIN:AVAILABLE + UID:57DD4AAF-3835-46B5-8A39-B3B253157F01 + SUMMARY:Monday to Friday from 9:00 to 17:00 + DTSTART;TZID=America/Denver:20111023T090000 + DTEND;TZID=America/Denver:20111023T170000 + RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR + LOCATION:Denver + END:AVAILABLE + END:VAVAILABILITY + BEGIN:VAVAILABILITY + ORGANIZER:mailto:bernard@example.com + UID:1852F9E1-E0AA-4572-B4C4-ED1680A4DA40 + DTSTAMP:20111005T133225Z + DTSTART;TZID=America/Montreal:20111030T030000 + BEGIN:AVAILABLE + UID:D27C421F-16C2-4ECB-8352-C45CA352C72A + SUMMARY:Monday to Friday from 9:00 to 17:00 + DTSTART;TZID=America/Montreal:20111030T090000 + DTEND;TZID=America/Montreal:20111030T170000 + RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR + LOCATION:Montreal + END:AVAILABLE + END:VAVAILABILITY + + + + + + + +Daboo & Douglass Standards Track [Page 9] + +RFC 7953 Calendar Availability August 2016 + + +3.2. Busy Time Type + + Property Name: BUSYTYPE + + Purpose: This property specifies the default busy time type. + + Value Type: TEXT + + Property Parameters: IANA and nonstandard property parameters can be + specified on this property. + + Conformance: This property can be specified within "VAVAILABILITY" + calendar components. + + Format Definition: This property is defined by the following + notation: + + busytype = "BUSYTYPE" busytypeparam ":" busytypevalue CRLF + + busytypeparam = *(";" other-param) + + busytypevalue = "BUSY" / "BUSY-UNAVAILABLE" / + "BUSY-TENTATIVE" / iana-token / x-name + ; Default is "BUSY-UNAVAILABLE". + + Description: This property is used to specify the default busy time + type. The values correspond to those used by the "FBTYPE" + parameter used on a "FREEBUSY" property, with the exception that + the "FREE" value is not used in this property. If not specified + on a component that allows this property, the default is "BUSY- + UNAVAILABLE". + + Example: The following is an example of this property: + + BUSYTYPE:BUSY + +4. Combining VAVAILABILITY Components + + The "VAVAILABILITY" component allows a calendar user to describe + their availability over extended periods of time through the use of + recurrence patterns. This availability might be relatively constant + from year to year. + + However, there is usually some degree of irregularity, as people take + vacations or perhaps spend a few weeks at a different office. For + that period of time there is a need to redefine their availability. + Rather than modify their existing availability, the "PRIORITY" + property allows new "VAVAILABILITY" components to override others of + + + +Daboo & Douglass Standards Track [Page 10] + +RFC 7953 Calendar Availability August 2016 + + + lower ordinal priority. Note that iCalendar [RFC5545] defines the + "PRIORITY" property such that a value of 0 is undefined, 1 is the + highest priority, and 9 is the lowest. + + When combining "VAVAILABILITY" components, an absence of a "PRIORITY" + property or a value of 0 implies the lowest level of priority. When + two or more VAVAILABILITY components overlap, and they have the same + PRIORITY value, the overlapping busy time type is determined by the + following order: BUSY > BUSY-UNAVAILABLE > BUSY-TENTATIVE. That is, + if one component has a BUSYTYPE set to BUSY and the other has + BUSYTYPE set to BUSY-UNAVAILABLE, then the effective busy time type + over the time range that they overlap would be BUSY. It is up to the + creator of such components to ensure that combining them produces a + consistent and expected result. + + To calculate the available time, order the intersecting + "VAVAILABILITY" components by priority (the lowest to highest + "PRIORITY" values are 0, 9, 8, 7, 6, 5, 4, 3, 2, 1). + + Step through the resulting list of "VAVAILABILITY" components. For + each, the time range covered by the "VAVAILABILITY" component is set + to busy and then portions of it defined by the "AVAILABLE" components + in the "VAVAILABILITY" component are set to free. + + Note that, if any "VAVAILABILITY" component completely covers the + date range of interest, then any lower priority "VAVAILABILITY" + components can be ignored. + + Typically, a calendar user's "default" availability (e.g., business + hours of Monday through Friday, 9:00 am to 5:00 pm) would use the + lowest level of priority: zero. Any overrides to the "default" would + use higher levels as needed. To avoid having to keep readjusting the + "PRIORITY" property value when an override has to be "inserted" + between two existing components, priority values SHOULD be "spaced + out" over the full range of values. The table below illustrates this + via an example. The first row shows the priority range from low to + high, the second row shows the corresponding "PRIORITY" property + value, and the third row shows which "VAVAILABILITY" component has + that priority. The "default" availability is created with priority + zero (shown as {a} in the table), then the first override created + with priority 5 (shown as {b} in the table), a subsequent + availability can be inserted between the two by using priority 7 + (shown as {c} in the table), and another, taking precedence over all + existing ones, with priority 3 (shown as {d} in the table). As seen + in the table, additional "slots" are open for more "VAVAILABILITY" + components to be added with other priorities if needed. + + + + + +Daboo & Douglass Standards Track [Page 11] + +RFC 7953 Calendar Availability August 2016 + + + +-----+----+----+-----+----+-----+----+-----+----+------+ + | Low | | | | | | | | | High | + +-----+----+----+-----+----+-----+----+-----+----+------+ + | 0 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | + +-----+----+----+-----+----+-----+----+-----+----+------+ + | {a} | | | {c} | | {b} | | {d} | | | + +-----+----+----+-----+----+-----+----+-----+----+------+ + +5. Calculating Free-Busy Time + + This section describes how free-busy time information for a calendar + user is calculated in the presence of "VAVAILABILITY" calendar + components. + + An iCalendar "VFREEBUSY" component is used to convey "rolled-up" + free-busy time information for a calendar user. This can be + generated as the result of an iTIP [RFC5546] free-busy request or + through some other mechanism (e.g., a CalDAV calendar-access + CALDAV:free-busy-query REPORT). + + When one or more "VAVAILABILITY" components are present and intersect + the time range for the free-busy request, first the available time is + calculated, as outlined in Section 4. Once that is done, regular + "VEVENT" and "VFREEBUSY" components can be "overlaid" in the usual + way to block out time. + + An example procedure for this is as follows: + + 1. Initially mark the entire period of the free-busy request as + free. + + 2. For each "VAVAILABILITY" component ordered by PRIORITY (lowest to + highest): + + A. Determine if the "VAVAILABILITY" intersects the time range of + the free-busy request. If not, ignore it. + + B. Determine if the "VAVAILABILITY" is completely overridden by + a higher priority component. If so, ignore it. + + C. For the time period covered by the "VAVAILABILITY" component, + mark time in the free-busy request result set as busy, using + the busy time type derived from the "BUSYTYPE" property in + the "VAVAILABILITY" component. + + D. Append the "VAVAILABILITY" component to a list of components + for further processing in step 3, if it has not been ignored. + + + + +Daboo & Douglass Standards Track [Page 12] + +RFC 7953 Calendar Availability August 2016 + + + 3. For each "VAVAILABILITY" component in the list resulting from + step 2, in order from the first item to the last item: + + A. For each "AVAILABLE" component in the "VAVAILABILITY" + component: + + i. Expand all recurring instances, taking into account + overridden instances, ignoring instances or parts of + instances that fall outside of the free-busy request + time range or the time period specified by the + "VAVAILABILITY" component. + + ii. For each instance, mark the corresponding time in the + free-busy request result set as free. + + 4. For each "VEVENT" or "VFREEBUSY" component, apply normal free- + busy processing within the free-busy request time range. + +5.1. Examples + + In the examples below, a table is used to represent time slots for + the period of a free-busy request. Each time slot is two hours long. + The column header represents the hours from midnight local time. + Each row below the column headers represents a step in the free-busy + result set determination, following the procedure outlined above. + + Each cell in the rows below the column header contains a single + character that represents the free-busy type for the corresponding + time period at the end of the process step represented by the row. + The characters in the row are: + + F Represents "FREE" time in that slot. + + B Represents "BUSY" time in that slot. + + U Represents "BUSY-UNAVAILABLE" time in that slot. + + T Represents "BUSY-TENTATIVE" time in that slot. + + I Represents data to be ignored in that slot (as per step 2.B + above). + +5.1.1. Simple Example + + Appendix A shows the user's calendar. This includes one + "VAVAILABILITY" component giving available time within the requested + time range of 8:00 am to 6:00 pm, together with one "VEVENT" + component representing a two hour meeting starting at 12:00 pm. + + + +Daboo & Douglass Standards Track [Page 13] + +RFC 7953 Calendar Availability August 2016 + + + A free-busy request for Monday, 6th November 2011, midnight to + midnight in the America/Montreal time zone would be calculated as + follows using the steps described above. + + +------+----+----+----+----+----+----+----+----+----+----+----+----+ + | Step | 0 | 2 | 4 | 6 | 8 | 10 | 12 | 14 | 16 | 18 | 20 | 22 | + +------+----+----+----+----+----+----+----+----+----+----+----+----+ + | 1. | F | F | F | F | F | F | F | F | F | F | F | F | + | 2. | U | U | U | U | U | U | U | U | U | U | U | U | + | 3. | U | U | U | U | F | F | F | F | F | U | U | U | + | 4. | U | U | U | U | F | F | B | F | F | U | U | U | + +------+----+----+----+----+----+----+----+----+----+----+----+----+ + +5.1.2. Further Example + + Appendix B shows another way to represent the availability of the + traveling worker shown above. Here we represent their base + availability of Monday through Friday, 8:00 am to 6:00 pm each day + with a "VAVAILABILITY" with default "PRIORITY" (there is no "DTEND" + property so that this availability is unbounded). For the week the + calendar user is working in Denver (October 23rd through October + 30th), we represent their availability with a "VAVAILABILITY" + component with priority 1, which overrides the base availability. + There is also a two hour meeting starting at 12:00 pm (in the + America/Denver time zone). + + A free-busy request for Monday, 24th October 2011, midnight to + midnight in the America/Montreal time zone, would be calculated as + follows using the steps described above. Note that there is a two + hour offset in the in the available time, compared to the previous + example, due to the two hour difference between the time zone of the + free-busy request and the time zone of the user's availability and + meeting. "2.P0" shows the base availability, and "2.P1" shows the + higher priority availability. "3.P1" only shows the higher priority + availability contributing to the overall free-busy since the default + availability is ignored (as per step 2.B described above). + + +------+----+----+----+----+----+----+----+----+----+----+----+----+ + | Step | 0 | 2 | 4 | 6 | 8 | 10 | 12 | 14 | 16 | 18 | 20 | 22 | + +------+----+----+----+----+----+----+----+----+----+----+----+----+ + | 1. | F | F | F | F | F | F | F | F | F | F | F | F | + | 2.P0 | I | I | I | I | I | I | I | I | I | I | I | I | + | 2.P1 | U | U | U | U | U | U | U | U | U | U | U | U | + | 3.P1 | U | U | U | U | U | F | F | F | F | F | U | U | + | 4. | U | U | U | U | U | F | F | B | F | F | U | U | + +------+----+----+----+----+----+----+----+----+----+----+----+----+ + + + + + +Daboo & Douglass Standards Track [Page 14] + +RFC 7953 Calendar Availability August 2016 + + +6. Use with iTIP + + This specification does not define how "VAVAILABILITY" components are + used in scheduling messages sent using the iTIP [RFC5546] protocol. + It is expected that future specifications will define how iTIP + scheduling can make use of "VAVAILABILITY" components. + +7. CalDAV Extensions + +7.1. CalDAV Requirements Overview + + This section lists what functionality is required of a CalDAV server, + which supports "VAVAILABILITY" components in stored calendar data. A + server: + + o MUST advertise support for "VAVAILABILITY" components in + CALDAV:supported-calendar-component-set properties on calendars + that allow storing of such components; + + o MUST support CALDAV:free-busy-query REPORTs that aggregate the + information in any "VAVAILABILITY" components in the calendar + collections targeted by the request; + + o MUST support "VAVAILABILITY" components stored in a + CALDAV:calendar-availability Web Distributed Authoring and + Versioning (WebDAV) property on a CalDAV scheduling Inbox + collection, if the CalDAV calendar-auto-schedule feature is + supported; + + o MUST support iTIP [RFC5546] free-busy requests that aggregate the + information in any "VAVAILABILITY" components in calendar + collections that contribute to free-busy, or in any + "VAVAILABILITY" components stored in the CALDAV:calendar- + availability property on the CalDAV scheduling Inbox collection of + the calendar user targeted by the iTIP free-busy request, if the + CalDAV calendar-auto-schedule feature is available. + + Processing of "VAVAILABILITY" components MUST conform to all the + requirements CalDAV imposes on calendar object resources (see + Section 4.1 of [RFC4791]). + + + + + + + + + + + +Daboo & Douglass Standards Track [Page 15] + +RFC 7953 Calendar Availability August 2016 + + +7.2. New Features in CalDAV + +7.2.1. Calendar Availability Support + + A server supporting the features described in this document MUST + include "calendar-availability" as a field in the DAV response header + from an OPTIONS request. A value of "calendar-availability" in the + DAV response header indicates to clients that the server supports all + the requirements specified in this document. + +7.2.1.1. Example: Using OPTIONS for the Discovery of Calendar + Availability Support + + >> Request << + + OPTIONS /home/bernard/calendars/ HTTP/1.1 + Host: cal.example.com + + >> Response << + + HTTP/1.1 200 OK + Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE + Allow: PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL + DAV: 1, 2, 3, access-control, calendar-access, + calendar-availability + Date: Fri, 11 Nov 2005 09:32:12 GMT + Content-Length: 0 + + In this example, the OPTIONS method returns the value "calendar- + availability" in the DAV response header to indicate that the + collection "/home/bernard/calendars/" supports the new features + defined in this specification. + +7.2.2. CalDAV Time Range Queries + + Section 9.9 of [RFC4791] describes how to specify time ranges to + limit the set of calendar components returned by the server. This + specification extends [RFC4791] to describe how to apply time range + filtering to "VAVAILABILITY" components. + + A "VAVAILABILITY" component is said to overlap a given time range if + the condition for the corresponding component state specified in the + table below is satisfied. The conditions depend on the presence of + the "DTSTART", "DTEND", and "DURATION" properties in the + "VAVAILABILITY" component. Note that, as specified above, the + "DTEND" value MUST be a "DATE-TIME" value equal to or after the + "DTSTART" value, if specified. + + + + +Daboo & Douglass Standards Track [Page 16] + +RFC 7953 Calendar Availability August 2016 + + + +------------------------------------------------------------+ + | VAVAILABILITY has the DTSTART property? | + | +--------------------------------------------------------+ + | | VAVAILABILITY has the DTEND property? | + | | +----------------------------------------------------+ + | | | VAVAILABILITY has the DURATION property? | + | | | +------------------------------------------------+ + | | | | Condition to evaluate | + +---+---+---+------------------------------------------------+ + | Y | Y | N | (start < DTEND AND end > DTSTART) | + +---+---+---+------------------------------------------------+ + | Y | N | Y | (start < DTSTART+DURATION AND end > DTSTART) | + +---+---+---+------------------------------------------------+ + | Y | N | N | (end > DTSTART) | + +---+---+---+------------------------------------------------+ + | N | Y | N | (start < DTEND) | + +---+---+---+------------------------------------------------+ + | N | N | * | TRUE | + +---+---+---+------------------------------------------------+ + +7.2.3. CALDAV:free-busy-query REPORT + + A CALDAV:free-busy-query REPORT can be executed on a calendar + collection that contains iCalendar "VAVAILABILITY" components. When + that occurs, the server MUST aggregate the information in any + "VAVAILABILITY" components when generating the free-busy response, as + described in Section 5. + +7.2.4. CALDAV:calendar-availability Property + + Name: calendar-availability + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Defines a "VAVAILABILITY" component that will be used in + calculating free-busy time when an iTIP free-busy request is + targeted at the calendar user who owns the Inbox. + + Conformance: This property MAY be protected and SHOULD NOT be + returned by a PROPFIND DAV:allprop request. Support for this + property is REQUIRED. The value of this property MUST be a valid + iCalendar object containing only one "VAVAILABILITY" component, + and optionally, "VTIMEZONE" components - other iCalendar + components MUST NOT be present. "VTIMEZONE" components SHOULD NOT + be present if [RFC7809] is in effect. For more complex + availability scenarios, clients can store multiple "VAVAILABILITY" + components in the calendar user's calendar collections. + + + + +Daboo & Douglass Standards Track [Page 17] + +RFC 7953 Calendar Availability August 2016 + + + Description: This property allows a user to specify their + availability by including an "VAVAILABILITY" component in the + value of this property. If present, the server MUST use this + "VAVAILABILITY" component when determining free-busy information + as part of an iTIP free-busy request being handled by the server. + + Definition: + + <!ELEMENT calendar-availability (#PCDATA) > + ; Data value MUST be an iCalendar object containing + ; "VAVAILABILITY" or "VTIMEZONE" components. + + Example: + + <C:calendar-availability xmlns:D="DAV:" + xmlns:C="urn:ietf:params:xml:ns:caldav" + >BEGIN:VCALENDAR + CALSCALE:GREGORIAN + PRODID:-//example.com//iCalendar 2.0//EN + VERSION:2.0 + BEGIN:VAVAILABILITY + UID:9BADC1F6-0FC4-44BF-AC3D-993BEC8C962A + DTSTAMP:20111005T133225Z + DTSTART;TZID=America/Montreal:20111002T000000 + BEGIN:AVAILABLE + UID:6C9F69C3-BDA8-424E-B2CB-7012E796DDF7 + SUMMARY:Monday to Friday from 9:00 to 18:00 + DTSTART;TZID=America/Montreal:20111002T090000 + DTEND;TZID=America/Montreal:20111002T180000 + RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR + END:AVAILABLE + END:VAVAILABILITY + END:VCALENDAR + </C:calendar-availability> + +7.2.5. iTIP Free-Busy Requests + + The CalDAV calendar-auto-schedule feature (see Section 5 of + [RFC6638]) includes a mechanism for free-busy information to be + requested via the CalDAV protocol. Any "VAVAILABILITY" components in + any calendar collections targeted during such a request MUST be + included as part of the calculation of the overall free-busy + information. In addition, the "VAVAILABILITY" component specified in + the CALDAV:calendar-availability property on the owner's Inbox MUST + also be included in the free-busy calculation. Processing of all + such "VAVAILABILITY" components is done as per Section 5. + + + + + +Daboo & Douglass Standards Track [Page 18] + +RFC 7953 Calendar Availability August 2016 + + +8. Security Considerations + + Calculation of availability information, particularly with multiple + overlapping time ranges, can be complex, and CalDAV servers MUST + limit the complexity of such data stored by a client. + + An attacker able to "inject" availability information into a calendar + user's calendar data could ensure that the user never appears free + for meetings or appears free at inappropriate times. Calendar + systems MUST ensure that availability information for a calendar user + can only be modified by authorized users. + + Security considerations in [RFC5545], [RFC5546], [RFC4791], + [RFC6638], and [RFC7809] MUST also be adhered to. + +9. Privacy Considerations + + Free-busy and availability information can be used by attackers to + infer the whereabouts or overall level of "activity" of the + corresponding calendar user. Any calendar system that allows a user + to expose their free-busy and availability information MUST limit + access to that information to only authorized users. + + When "VAVAILABILITY" components are sent to or shared with other + calendar users, care has to be taken not to expose more information + than is needed by each recipient. For example, a business owner will + likely not want their customers to know where they might be or what + they might be doing, but family members might be willing to expose + such information to each other. Thus, calendaring systems allowing + "VAVAILABILITY" components to be sent or shared to other calendar + users MUST provide a way for nonessential properties to be removed + (e.g., "SUMMARY", "LOCATION", and "DESCRIPTION"). + + iCalendar "VFREEBUSY" information generated from "VAVAILABILITY" + components MUST NOT include information other than busy or free time + periods. In particular, user specified property values such as + "SUMMARY", "LOCATION", and "DESCRIPTION" MUST NOT be copied into the + free-busy result data. + + Privacy considerations in [RFC5545], [RFC5546], [RFC4791], [RFC6638], + and [RFC7809] MUST also be adhered to. + + + + + + + + + + +Daboo & Douglass Standards Track [Page 19] + +RFC 7953 Calendar Availability August 2016 + + +10. IANA Considerations + +10.1. Component Registrations + + This document defines the following new iCalendar components, which + have been added to the registry defined in Section 8.3.1 of + [RFC5545]: + + +---------------+---------+------------------------+ + | Component | Status | Reference | + +---------------+---------+------------------------+ + | VAVAILABILITY | Current | RFC 7953, Section 3.1 | + | AVAILABLE | Current | RFC 7953, Section 3.1 | + +---------------+---------+------------------------+ + +10.2. Property Registrations + + This documents defines the following new iCalendar properties, which + have been added to the registry defined in Section 8.3.2 of + [RFC5545]: + + +----------+---------+------------------------+ + | Property | Status | Reference | + +----------+---------+------------------------+ + | BUSYTYPE | Current | RFC 7953, Section 3.2 | + +----------+---------+------------------------+ + +11. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, + "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, + DOI 10.17487/RFC4791, March 2007, + <http://www.rfc-editor.org/info/rfc4791>. + + [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and + Scheduling Core Object Specification (iCalendar)", + RFC 5545, DOI 10.17487/RFC5545, September 2009, + <http://www.rfc-editor.org/info/rfc5545>. + + [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent + Interoperability Protocol (iTIP)", RFC 5546, + DOI 10.17487/RFC5546, December 2009, + <http://www.rfc-editor.org/info/rfc5546>. + + + +Daboo & Douglass Standards Track [Page 20] + +RFC 7953 Calendar Availability August 2016 + + + [RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to + CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012, + <http://www.rfc-editor.org/info/rfc6638>. + + [RFC7809] Daboo, C., "Calendaring Extensions to WebDAV (CalDAV): + Time Zones by Reference", RFC 7809, DOI 10.17487/RFC7809, + March 2016, <http://www.rfc-editor.org/info/rfc7809>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Daboo & Douglass Standards Track [Page 21] + +RFC 7953 Calendar Availability August 2016 + + +Appendix A. Example Calendar #1 + + BEGIN:VCALENDAR + CALSCALE:GREGORIAN + PRODID:-//example.com//iCalendar 2.0//EN + VERSION:2.0 + BEGIN:VEVENT + DTSTAMP:20111113T044111Z + DTSTART;TZID=America/Montreal:20111106T120000 + DURATION:PT2H + SUMMARY:Meeting + UID:768CB0C2-8642-43F7-A6C4-F8BB04B829B4 + END:VEVENT + BEGIN:VAVAILABILITY + UID:452DFCA7-3203-4A3D-9A9A-99753A383B41 + DTSTAMP:20111005T133225Z + DTSTART;TZID=America/Montreal:20111002T000000 + BEGIN:AVAILABLE + UID:466D5C68-5C4A-4078-AF5D-9C55EA9145D7 + SUMMARY:Monday to Friday from 8:00 to 18:00 + DTSTART;TZID=America/Montreal:20111002T080000 + DTEND;TZID=America/Montreal:20111002T180000 + RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR + END:AVAILABLE + END:VAVAILABILITY + END:VCALENDAR + + + + + + + + + + + + + + + + + + + + + + + + + +Daboo & Douglass Standards Track [Page 22] + +RFC 7953 Calendar Availability August 2016 + + +Appendix B. Example Calendar #2 + + BEGIN:VCALENDAR + CALSCALE:GREGORIAN + PRODID:-//example.com//iCalendar 2.0//EN + VERSION:2.0 + BEGIN:VEVENT + DTSTAMP:20111113T044111Z + DTSTART;TZID=America/Denver:20111106T120000 + DURATION:PT2H + SUMMARY:Lunch meeting in Denver + UID:2346C09A-42BF-439E-916C-FC83AF869171 + END:VEVENT + BEGIN:VAVAILABILITY + ORGANIZER:mailto:bernard@example.com + UID:627A87FA-E5F1-43C0-B3B1-567DA10F2A83 + DTSTAMP:20111005T133225Z + DTSTART;TZID=America/Montreal:20111002T000000 + BEGIN:AVAILABLE + UID:A833E850-892B-43F6-98B6-C15A6BFC5D27 + SUMMARY:Monday to Friday from 9:00 to 17:00 + DTSTART;TZID=America/Montreal:20111002T080000 + DTEND;TZID=America/Montreal:20111002T180000 + RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR + LOCATION:Montreal + END:AVAILABLE + END:VAVAILABILITY + BEGIN:VAVAILABILITY + ORGANIZER:mailto:bernard@example.com + UID:F01411E3-38B8-4490-8A1F-0CCEC57A0943 + DTSTAMP:20111005T133225Z + DTSTART;TZID=America/Denver:20111023T000000 + DTEND;TZID=America/Denver:20111030T000000 + PRIORITY:1 + BEGIN:AVAILABLE + UID:A35AA091-3846-48ED-96F6-881E8A0D0A93 + SUMMARY:Monday to Friday from 9:00 to 17:00 + DTSTART;TZID=America/Denver:20111023T080000 + DTEND;TZID=America/Denver:20111023T180000 + RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR + LOCATION:Denver + END:AVAILABLE + END:VAVAILABILITY + END:VCALENDAR + + + + + + + +Daboo & Douglass Standards Track [Page 23] + +RFC 7953 Calendar Availability August 2016 + + +Acknowledgements + + Thanks to the following for providing feedback: Toby Considine, + Bernard Desruisseaux, Alexey Melnikov, Daniel Migault, Ken Murchison, + Evert Pot, and Dave Thewlis. This specification came about via + discussions at the Calendaring and Scheduling Consortium. + +Authors' Addresses + + Cyrus Daboo + Apple Inc. + 1 Infinite Loop + Cupertino, CA 95014 + United States of America + + Email: cyrus@daboo.name + URI: http://www.apple.com/ + + + Michael Douglass + Spherical Cow Group + 226 3rd Street + Troy, NY 12180 + United States of America + + Email: mdouglass@sphericalcowgroup.com + URI: http://sphericalcowgroup.com + + + + + + + + + + + + + + + + + + + + + + + + +Daboo & Douglass Standards Track [Page 24] + |