RFC 6638
Scheduling Extensions to CalDAV
Scheduling Extensions to CalDAV 🎀
Okay bestie, this is RFC 6638, and it's giving main character energy for calendars 📅💅 Here's the title block tea ☕ (facts only, no columns):
- RFC number: 6638
- Title: Scheduling Extensions to CalDAV
- Authors: C. Daboo (Apple Inc.) and B. Desruisseaux (Oracle)
- Category: Standards Track
- ISSN: 2070-1721
- Date: June 2012
- Updates: 4791, 5546 (that's RFC 4791 and RFC 5546 👀)
- Obsoletes: nothing is listed in the title block
The big deal: this doc updates RFC 4791 and RFC 5546, so those two are getting a glow-up too ✨
Abstract 💖
Okay so, this doc adds extensions to the "calendar-access" feature of CalDAV (Calendaring Extensions to WebDAV) 🦋 The goal is one standard way to do scheduling stuff with iCalendar-based calendar components, so every server and client is speaking the same language, no cap 🫶
It also defines the "calendar-auto-schedule" feature of CalDAV. Literally the whole vibe 💜
Status of This Memo 🌸
This is an Internet Standards Track document 🔥
It's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 👑 If you want more info on Internet Standards, check Section 2 of RFC 5741.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6638 🧚
Copyright Notice 🌈
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 🎀
Okay, the legal bit, but it matters! This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document 🙈 Any Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 💅
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that older material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So without an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍
Table of Contents 📚
1. Introduction ....................................................5
1.1. Terminology ................................................6
1.2. Notational Conventions .....................................7
1.3. XML Namespaces and Processing ..............................7
2. Scheduling Support ..............................................8
2.1. Scheduling Outbox Collection ...............................9
2.1.1. CALDAV:schedule-outbox-URL Property ................10
2.2. Scheduling Inbox Collection ...............................10
2.2.1. CALDAV:schedule-inbox-URL Property .................11
2.3. Calendaring Reports Extensions ............................12
2.4. Additional Principal Properties ...........................12
2.4.1. CALDAV:calendar-user-address-set Property ..........12
2.4.2. CALDAV:calendar-user-type Property .................13
3. Scheduling Operations ..........................................14
3.1. Identifying Scheduling Object Resources ...................14
3.2. Handling Scheduling Object Resources ......................15
3.2.1. Organizer Scheduling Object Resources ..............15
3.2.1.1. Create ....................................16
3.2.1.2. Modify ....................................17
3.2.1.3. Remove ....................................18
3.2.2. Attendee Scheduling Object Resources ...............18
3.2.2.1. Allowed "Attendee" Changes ................18
3.2.2.2. Create ....................................19
3.2.2.3. Modify ....................................20
3.2.2.4. Remove ....................................21
3.2.3. HTTP Methods .......................................21
3.2.3.1. PUT .......................................22
3.2.3.2. DELETE ....................................22
3.2.3.3. COPY ......................................23
3.2.3.4. MOVE ......................................24
3.2.4. Additional Method Preconditions ....................24
3.2.4.1. CALDAV:unique-scheduling-object-resource
Precondition ..............................24
3.2.4.2. CALDAV:same-organizer-in-all-components
Precondition ..............................25
3.2.4.3. CALDAV:allowed-organizer-scheduling-
object-change Precondition .............25
3.2.4.4. CALDAV:allowed-attendee-scheduling-
object-change Precondition .............26
3.2.5. DTSTAMP and SEQUENCE Properties ....................26
3.2.6. Restrict Recurrence Instances Sent to "Attendees" ..27
3.2.7. Forcing the Server to Send a Scheduling Message ....27
3.2.8. "Attendee" Participation Status ....................28
3.2.9. Schedule Status Values .............................29
3.2.10. Avoiding Conflicts when Updating Scheduling Object
Resources .........................................31
3.2.10.1. PUT .....................................33
3.2.10.2. DELETE, COPY, or MOVE ...................33
4. Processing Incoming Scheduling Messages ........................34
4.1. Processing "Organizer" Requests, Additions, and
Cancellations .............................................34
4.2. Processing "Attendee" Replies .............................35
4.3. Default Calendar Collection ...............................35
4.3.1. Additional Method Preconditions ....................36
4.3.1.1. CALDAV:default-calendar-needed
Precondition ..............................36
4.3.1.2. CALDAV:valid-schedule-default-calendar-URL
Precondition ..............................36
5. Request for Busy Time Information ..............................37
5.1. Status Codes ..............................................38
5.2. Additional Method Preconditions ...........................38
5.2.1. CALDAV:valid-scheduling-message Precondition .......38
5.2.2. CALDAV:valid-organizer Precondition ................39
6. Scheduling Privileges ..........................................39
6.1. Privileges on Scheduling Inbox Collections ................39
6.1.1. CALDAV:schedule-deliver Privilege ..................40
6.1.2. CALDAV:schedule-deliver-invite Privilege ...........40
6.1.3. CALDAV:schedule-deliver-reply Privilege ............40
6.1.4. CALDAV:schedule-query-freebusy Privilege ...........40
6.2. Privileges on Scheduling Outbox Collections ...............40
6.2.1. CALDAV:schedule-send Privilege .....................41
6.2.2. CALDAV:schedule-send-invite Privilege ..............41
6.2.3. CALDAV:schedule-send-reply Privilege ...............41
6.2.4. CALDAV:schedule-send-freebusy Privilege ............41
6.3. Aggregation of Scheduling Privileges ......................42
7. Additional iCalendar Property Parameters .......................42
7.1. Schedule Agent Parameter ..................................42
7.2. Schedule Force Send Parameter .............................44
7.3. Schedule Status Parameter .................................45
8. Additional Message Header Fields ...............................46
8.1. Schedule-Reply Request Header .............................46
8.2. Schedule-Tag Response Header ..............................46
8.3. If-Schedule-Tag-Match Request Header ......................47
9. Additional WebDAV Properties ...................................47
9.1. CALDAV:schedule-calendar-transp Property ..................47
9.2. CALDAV:schedule-default-calendar-URL Property .............48
9.3. CALDAV:schedule-tag Property ..............................49
10. XML Element Definitions .......................................50
10.1. CALDAV:schedule-response XML Element .....................50
10.2. CALDAV:response XML Element ..............................50
10.3. CALDAV:recipient XML Element .............................50
10.4. CALDAV:request-status XML Element ........................51
11. Security Considerations .......................................51
11.1. Preventing Denial-of-Service Attacks .....................51
11.2. Verifying Scheduling Operations ..........................52
11.3. Verifying Busy Time Information Requests .................52
11.4. Privacy Issues ...........................................53
11.5. Mitigation of iTIP Threats ...............................53
12. IANA Considerations ...........................................54
12.1. Message Header Field Registrations .......................54
12.1.1. Schedule-Reply ....................................54
12.1.2. Schedule-Tag ......................................54
12.1.3. If-Schedule-Tag-Match .............................54
12.2. iCalendar Property Parameter Registrations ...............55
12.3. iCalendar REQUEST-STATUS Value Registrations .............55
12.4. Additional iCalendar Elements Registries .................55
12.4.1. Schedule Agent Values Registry ....................56
12.4.2. Schedule Force Send Values Registry ...............56
13. Acknowledgements ..............................................56
14. References ....................................................57
14.1. Normative References .....................................57
14.2. Informative References ...................................58
Appendix A. Scheduling Privileges Summary .........................59
A.1. Scheduling Inbox Privileges ................................59
A.2. Scheduling Outbox Privileges ...............................60
Appendix B. Example Scheduling Operations .........................60
B.1. Example: "Organizer" Inviting Multiple "Attendees" .........61
B.2. Example: "Attendee" Receiving an Invitation ................63
B.3. Example: "Attendee" Replying to an Invitation ..............64
B.4. Example: "Organizer" Receiving a Reply to an Invitation ....66
B.5. Example: "Organizer" Requesting Busy Time Information ......69
B.6. Example: User Attempting to Invite "Attendee" on
Behalf of "Organizer" ......................................71
B.7. Example: "Attendee" Declining an Instance of a
Recurring Event ............................................72
B.8. Example: "Attendee" Removing an Instance of a
Recurring Event ............................................75Part 1 of 14 wrapped 🎀 Next up is Section 1, Introduction, so stay tuned bestie 🫶💜
1. Introduction ✨
okay so this doc adds extensions to the CalDAV "calendar-access" feature [RFC4791] so calendar users can schedule iCalendar components [RFC5545] with each other 📅💖
It borrows the scheduling methods from iTIP [RFC5546], which means you can do schedule, reschedule, respond to a scheduling request, or cancel calendar components, plus search for busy time info 🫶 BUT, and this is important bestie, publishing, countering, delegating, refreshing, forwarding, and replacing the "Organizer" of a component are NOT covered here 🙈 the doc says future extensions might handle those, so we wait 🧚
This is a client/server scheduling protocol, which means the server is the one in charge of sending scheduling messages and processing the ones that come in 👑 the client just has to create, modify, or delete a calendar component and the server takes it from there and delivers the messages to the right people. The doc calls this "implicit scheduling" and honestly that's giving magic ✨
Only users on a single system are covered. Scheduling between CalDAV servers, or with some other calendaring system, is NOT defined here 💅 Still, servers can send and receive messages with "external" users (like through iMIP [RFC6047]), so it's not a total dead end 🌸
Quick map of the rest of the doc 🗺️
- Section 3 covers the automated "Scheduling Operations" where a client stores iCalendar data on a CalDAV server and the server reacts. There are three: "create", "modify", and "remove", picked by the HTTP method, plus a comparison between existing and new iCalendar data 🎀
- Section 4 covers how the server handles scheduling messages that come out of those operations 📬
- Section 5 covers freebusy requests that get an immediate response 🦋
- Section 6 covers the access control privileges for everything in here 🔐
Most of the examples are about events, but to-dos are fully supported too, so don't forget them 📝
This has been cooking for years and most CalDAV implementations already support it. Once this is published, all new CalDAV implementations are expected to support it by default 💜 Interop tests have been run regularly, and big issues with incompatible implementations aren't expected. ngl that's a W 🏆
1.1. Terminology
This spec reuses a lot of terms from iCalendar [RFC5545], iTIP [RFC5546], WebDAV [RFC4918], and CalDAV [RFC4791]. On top of those, here are the new ones 🧚
Scheduling object resource: A calendar object resource in a calendar collection that the server takes care of sending scheduling messages for, on behalf of the calendar collection's owner.
Organizer scheduling object resource: A scheduling object resource owned by the "Organizer".
Attendee scheduling object resource: A scheduling object resource owned by an "Attendee".
Scheduling operation: An add, change, or remove on a scheduling object resource that makes the server deliver scheduling messages to other calendar users.
Scheduling message: A calendar object that describes a scheduling operation, like schedule, reschedule, reply, or cancel.
Scheduling Outbox collection: The resource where busy time information requests get targeted.
Scheduling Inbox collection: The collection where incoming scheduling messages get delivered.
1.2. Notational Conventions
Here's the key word situation 🔑 The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc get interpreted the way [RFC2119] describes ⭐
The ABNF syntax used to define new iCalendar elements is from [RFC5234] 🍓
For new message header fields used with HTTP/1.1, the ABNF comes from Section 2.1 of [RFC2616]. Since that ABNF uses the basic production rules from Section 2.2 of [RFC2616], those rules apply here too 💅
The term "protected" shows up in the Conformance field of WebDAV property definitions, as defined in Section 15 of [RFC4918] 🔒
Roles in calendaring and scheduling are written in quoted text with each word capitalised, so "Organizer" refers to a calendar user's role in the scheduling protocol from [RFC5546] 🎀
1.3. XML Namespaces and Processing
This doc uses XML DTD fragments ([W3C.REC-xml-20081126], Section 3.2) purely as a notation thing 🧚 WebDAV request and response bodies can't be validated against a DTD, because of the extensibility rules in Section 17 of [RFC4918] and because every XML element that spec defines uses the "DAV:" namespace name. So here's the deal, the rules are:
- element names use the "DAV:" namespace,
- element ordering is irrelevant unless explicitly stated,
- extension elements (elements not already defined as valid child elements) can be added anywhere, except when explicitly stated otherwise, and
- extension attributes (attributes not already defined as valid for this element) can be added anywhere, except when explicitly stated otherwise.
The XML elements in this doc live in the "urn:ietf:params:xml:ns:caldav" namespace, registered by CalDAV [RFC4791] 🦋
When XML element types from "DAV:" and "urn:ietf:params:xml:ns:caldav" get mentioned outside an XML fragment, they're prefixed with "DAV:" and "CALDAV:" respectively 💜
This doc inherits, and sometimes extends, DTD productions from Section 14 of [RFC4918] 🌈
Heads up, some CalDAV XML element names match WebDAV ones but live in a different namespace. Don't mix them up 🙈
2. Scheduling Support ✨
A server that supports the features in this doc is REQUIRED to support the CalDAV "calendar-access" [RFC4791] feature 🫶 Servers include "calendar-auto-schedule" as a field in the DAV response header of an OPTIONS request on any resource that supports scheduling operations, properties, privileges, or methods 💖
This spec adds new collection resource types for managing scheduling object resources and scheduling privileges (see Section 6), and for providing scheduling functionality 🎀 The server is responsible for creating these collections, and clients have no way to create or delete them 👑
2.1. Scheduling Outbox Collection
A scheduling Outbox collection is the target for busy time information requests, and it manages privileges for outgoing scheduling requests 📤
A scheduling Outbox collection MUST report the DAV:collection and CALDAV:schedule-outbox XML elements in the value of the DAV:resourcetype property 🧚 The element type declaration for CALDAV:schedule-outbox is:
<!ELEMENT schedule-outbox EMPTY>Example:
<D:resourcetype xmlns:D="DAV:">
<D:collection/>
<C:schedule-outbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
</D:resourcetype>A scheduling Outbox collection MUST NOT be a child (at any depth) of a calendar collection resource 🙅♀️
These WebDAV properties from CalDAV "calendar-access" [RFC4791] MAY also be defined on scheduling Outbox collections. They apply to scheduling messages submitted to the Outbox with the POST method 💅
CALDAV:supported-calendar-component-setCALDAV:supported-calendar-dataCALDAV:max-resource-sizeCALDAV:min-date-timeCALDAV:max-date-timeCALDAV:max-attendees-per-instance
Child resources inside a scheduling Outbox collection are reserved for future revisions or extensions of this spec 🌸
The following WebDAV property is defined on principal resources. It's how you find the matching Outbox collection for that principal 🔍
2.1.1. CALDAV:schedule-outbox-URL Property
Name: schedule-outbox-URL
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Identifies the URL of the scheduling Outbox collection owned by the associated principal resource.
Protected: This property MAY be protected.
PROPFIND behavior: This property SHOULD NOT be returned by a PROPFIND DAV:allprop request (as defined in Section 14.2 of [RFC4918]) 🙈
COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations 📦
Description: A client needs this property to figure out where the current user's scheduling Outbox collection is, so it can send scheduling messages. If it's not there, the calendar user isn't enabled for sending scheduling messages on the server 💔
Definition:
<!ELEMENT schedule-outbox-URL (DAV:href)>2.2. Scheduling Inbox Collection 📬✨
okay so the scheduling Inbox collection is where all the incoming scheduling messages land 💌 it's basically your bestie's group chat notifications, aka requests from an "Organizer" or replies from an "Attendee" who said yes/no/maybe 🫶 it also handles who's allowed to schedule stuff, so it's giving main character energy 👑
A scheduling Inbox collection MUST report the DAV:collection and CALDAV:schedule-inbox XML elements in the value of the DAV:resourcetype property. The element type declaration for CALDAV:schedule-inbox is:
<!ELEMENT schedule-inbox EMPTY>Example:
<D:resourcetype xmlns:D="DAV:">
<D:collection/>
<C:schedule-inbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
</D:resourcetype>Scheduling Inbox collections MUST only contain calendar object resources that obey the restrictions specified in iTIP [RFC5546]. Consequently, scheduling Inbox collections MUST NOT contain any types of collection resources. 🙅♀️ The restrictions in Section 4.1 of CalDAV "calendar-access" [RFC4791] on calendar object resources in calendar collections (for example, Unique Identifier ("UID") uniqueness) do not apply to calendar object resources in a scheduling Inbox collection 🙈 so multiple calendar object resources in there can have the same "UID" property value (aka multiple scheduling messages for the same calendar component). iykyk 💅
A scheduling Inbox collection MUST NOT be a child (at any depth) of a calendar collection resource. 🚫
The following WebDAV properties specified in CalDAV "calendar-access" [RFC4791] MAY also be defined on scheduling Inbox collections and apply to scheduling messages delivered to the collection:
CALDAV:supported-calendar-component-setCALDAV:supported-calendar-dataCALDAV:max-resource-sizeCALDAV:min-date-timeCALDAV:max-date-timeCALDAV:max-instancesCALDAV:max-attendees-per-instanceCALDAV:calendar-timezone
The following WebDAV property is defined on principal resources and used to locate the corresponding Inbox collection for the associated principal. 🔎
2.2.1. CALDAV:schedule-inbox-URL Property 🗝️
- Name:
schedule-inbox-URL - Namespace:
urn:ietf:params:xml:ns:caldav - Purpose: Identify the URL of the scheduling Inbox collection owned by the associated principal resource.
- Protected: This property MAY be protected.
- PROPFIND behavior: This property SHOULD NOT be returned by a PROPFIND DAV:allprop request (as defined in Section 14.2 of [RFC4918]).
- COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations.
- Description: This property lets a client figure out where the current user's scheduling Inbox collection lives so scheduling messages can get processed 📍 If it's not present, the calendar user isn't set up to receive scheduling messages on the server 😭
- Definition:
<!ELEMENT schedule-inbox-URL (DAV:href)>2.3. Calendaring Reports Extensions 🧾
This specification extends the CALDAV:calendar-query and CALDAV:calendar-multiget REPORTs so they return results for calendar object resources in scheduling Inbox collections. ✨
When a CALDAV:calendar-query REPORT includes a time-range query and targets a scheduling Inbox collection, if any calendar object resources contain "VEVENT" calendar components that do not include a "DTSTART" iCalendar property (as allowed by iTIP [RFC5546]), then such components MUST always match the time-range query test. 🎯
Heads up: the CALDAV:free-busy-query REPORT is not supported on scheduling Inbox collections. 🙅♀️
2.4. Additional Principal Properties 🎀
This section defines new properties for WebDAV principal resources as defined in [RFC3744]. These properties are likely to be protected, but the server MAY allow them to be written by appropriate users. 🔐
2.4.1. CALDAV:calendar-user-address-set Property 📇
- Name: calendar-user-address-set
- Namespace: urn:ietf:params:xml:ns:caldav
- Purpose: Identify the calendar addresses of the associated principal resource.
- Protected: This property MAY be protected.
- PROPFIND behavior: This property SHOULD NOT be returned by a PROPFIND DAV:allprop request (as defined in Section 14.2 of [RFC4918]).
- COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations.
- Description: Support for this property is REQUIRED. 🫡 It's what maps calendar user addresses in iCalendar data to principal resources and their scheduling Inbox and Outbox collections 🗺️ If a user doesn't have a well-defined identifier for their calendar user address, the URI of their principal resource can be used instead. This property SHOULD be searchable using the DAV:principal-property-search REPORT, and the DAV:principal-search-property-set REPORT SHOULD identify it as such. If it's not present, the calendar user isn't enabled for scheduling on the server.
- Definition:
<!ELEMENT calendar-user-address-set (DAV:href*)>- Example:
<C:calendar-user-address-set xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:href>mailto:bernard@example.com</D:href>
<D:href>mailto:bernard.desruisseaux@example.com</D:href>
</C:calendar-user-address-set>2.4.2. CALDAV:calendar-user-type Property 🧚
- Name: calendar-user-type
- Namespace: urn:ietf:params:xml:ns:caldav
- Purpose: Identifies the calendar user type of the associated principal resource.
- Value: Same values allowed for the iCalendar "CUTYPE" property parameter defined in Section 3.2.3 of [RFC5545].
- Protected: This property MAY be protected.
- PROPFIND behavior: This property SHOULD NOT be returned by a PROPFIND DAV:allprop request (as defined in Section 14.2 of [RFC4918]).
- COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations.
- Description: Clients can search principal resources to look up "Attendees" on the server 🔍 and it's super useful to know, or filter by, certain kinds of calendar users (like only "people", or only "rooms") 🚪 This property MAY be defined on principal resources to show the type of calendar user for that principal. Its value is the same as the iCalendar "CUTYPE" property parameter you can use on "ATTENDEE" properties. This property SHOULD be searchable using the DAV:principal-property-search REPORT, and the DAV:principal-search-property-set REPORT SHOULD identify it as such.
- Definition:
<!ELEMENT calendar-user-type (#PCDATA)>- Example:
<C:calendar-user-type
xmlns:C="urn:ietf:params:xml:ns:caldav">INDIVIDUAL<
/C:calendar-user-type>3. Scheduling Operations 🗓️💖
okay so when a calendar object resource gets created, modified, or removed from a calendar collection, the server checks the calendar data to see if it's a scheduling object resource 👀 If it is, the server will automatically try to deliver a scheduling message to the right calendar users 📨 A few kinds of scheduling operations can happen here, equivalent to the iTIP "REQUEST", "REPLY", "CANCEL", and "ADD" operations. 🦋
3.1. Identifying Scheduling Object Resources 🔎
Calendar object resources that the server runs scheduling operations on are called scheduling object resources. There are two types: organizer scheduling object resources, and attendee scheduling object resources. 💅
A calendar object resource counts as a valid organizer scheduling object resource if the "ORGANIZER" iCalendar property is present and set in all the calendar components to a value that matches one of the calendar user addresses of the owner of the calendar collection. 👑
A calendar object resource counts as a valid attendee scheduling object resource if the "ORGANIZER" iCalendar property is present and set in all the calendar components to the same value, and that value doesn't match one of the calendar user addresses of the owner of the calendar collection, and if at least one of the "ATTENDEE" iCalendar property values matches one of the calendar user addresses of the owner of the calendar collection. 🧠
Attendee scheduling object resources are typically created by the server, with the resource landing in an appropriate calendar collection (see Section 4.3). 🫶
3.2. Handling Scheduling Object Resources 🎀
How the server handles a scheduling object resource depends on whether it's owned by the "Organizer" or by an "Attendee" specified in the calendar data. ✨
3.2.1. Organizer Scheduling Object Resources 🧑💼
An "Organizer" can create, modify, or remove a scheduling object resource, subject to access privileges, preconditions, and the restrictions defined in Section 4.1 of [RFC4791]. Each of these operations is described next, and how they get invoked via HTTP requests is covered in Section 3.2.3. 📝
The "Organizer" of a calendar component can also be an "Attendee" of that same component. In that case, the server MUST NOT send a scheduling message to the "Attendee" that matches the "Organizer". 🙅♀️ (no notifying yourself, periodt 💀)
The server SHOULD reject any attempt to set the "PARTSTAT" iCalendar property parameter value of the "ATTENDEE" iCalendar property of other users in the calendar object resource to a value other than "NEEDS-ACTION" if the "SCHEDULE-AGENT" property parameter value is not present or is set to the value "SERVER". 🚫
The server MAY reject attempts to create a scheduling object resource that specifies a "UID" property value already specified in a scheduling object resource contained in another calendar collection of the "Organizer". 🌈
3.2.1.1. Create ✨
okay bestie, when an "Organizer" creates a scheduling object resource, the server MUST inspect each "ATTENDEE" property to figure out whether to send a scheduling message 📨 The table below shows which iTIP method the server uses, depending on the "SCHEDULE-AGENT" property parameter (see Section 7.1) on each "ATTENDEE" property 💅
+------------------+-------------+
| SCHEDULE-AGENT | iTIP METHOD |
+------------------+-------------+
| SERVER (default) | REQUEST |
| | |
| CLIENT | -- |
| | |
| NONE | -- |
+------------------+-------------+the "SCHEDULE-STATUS" iCalendar property parameters get added or changed on the "ATTENDEE" iCalendar properties in the new scheduling object resource, as described in Section 7.3, with the value set as described in Section 3.2.9 🎀 this means the stored calendar data ends up looking different from what was sent in the HTTP request, so clients MAY reload the calendar data from the server to get the new server-generated state info 🔄
the server MUST add a "SCHEDULE-STATUS" iCalendar property parameter (see Section 7.3) to the "ATTENDEE" iCalendar property in the scheduling object resource being created, and set its value as described in Section 3.2.9 🌸 same deal as above: the created calendar object resource won't match the HTTP request data, so clients MAY reload the calendar data from the server to catch up on the server-generated state information. the big rule here is that servers MUST NOT set the "SCHEDULE-STATUS" property parameter on the "ATTENDEE" property of "Attendees" that they did not attempt to deliver a scheduling message to 🙅♀️ no spam, no cap.
the server MUST return an error with the CALDAV:allowed-organizer-scheduling-object-change precondition code (Section 3.2.4.3) when the "Organizer" tries to change the iCalendar data in a way that is forbidden 🚫 no sneaky edits, periodt.
3.2.1.2. Modify 🦋
when an "Organizer" modifies a scheduling object resource, the server MUST inspect each "ATTENDEE" property in both the original and the modified iCalendar data, on a per-instance basis, to decide whether to send a scheduling message 🧐 the table below shows the iTIP method the server uses, taking into account the "SCHEDULE-AGENT" property parameter (see Section 7.1) on each "ATTENDEE" property. the values "SERVER", "CLIENT", and "NONE" along the top and left side of the table are the "SCHEDULE-AGENT" parameter values on the "ATTENDEE" property, and "<Absent>" and "<Removed>" cover the cases where the "ATTENDEE" property isn't there (Original) or is getting removed (Modified) 🍓
+---------------+-----------------------------------------------+
| | Modified |
| +-----------+-----------+-----------+-----------+
| | <Removed> | SERVER | CLIENT | NONE |
| | | (default) | | |
+===+===========+===========+===========+===========+===========+
| | <Absent> | -- | REQUEST / | -- | -- |
| O | | | ADD | | |
| r +-----------+-----------+-----------+-----------+-----------+
| i | SERVER | CANCEL | REQUEST | CANCEL | CANCEL |
| g | (default) | | | | |
| i +-----------+-----------+-----------+-----------+-----------+
| n | CLIENT | -- | REQUEST / | -- | -- |
| a | | | ADD | | |
| l +-----------+-----------+-----------+-----------+-----------+
| | NONE | -- | REQUEST / | -- | -- |
| | | | ADD | | |
+---+-----------+-----------+-----------+-----------+-----------+the "SCHEDULE-STATUS" iCalendar property parameters get added or changed on the "ATTENDEE" iCalendar properties in the scheduling object resource being modified, as described in Section 7.3, with the value set as described in Section 3.2.9 ✨ again, the created calendar object resource ends up different from the HTTP request data, so clients MAY reload the calendar data from the server to grab the new server-generated state information 💖
the server MUST return an error with the CALDAV:allowed-organizer-scheduling-object-change precondition code (Section 3.2.4.3) when the "Organizer" tries to change the iCalendar data in a forbidden way 🙅♀️
3.2.1.3. Remove 💀
when an "Organizer" removes a scheduling object resource, the server MUST inspect each "ATTENDEE" property to decide whether to send a scheduling message 📭 the table below shows the iTIP method the server uses, taking into account the "SCHEDULE-AGENT" property parameter (see Section 7.1) on each "ATTENDEE" property 🌈
+------------------+-------------+
| SCHEDULE-AGENT | iTIP METHOD |
+------------------+-------------+
| SERVER (default) | CANCEL |
| | |
| CLIENT | -- |
| | |
| NONE | -- |
+------------------+-------------+3.2.2. Attendee Scheduling Object Resources 🧚
an "Attendee" can create, modify, or remove a scheduling object resource 🙌 each of these operations gets its own little breakdown next, and how they're triggered through HTTP requests is covered in Section 3.2.3.
3.2.2.1. Allowed "Attendee" Changes 👑
"Attendees" are allowed to make some changes to a scheduling object resource, but the big key properties like start time, end time, location, and summary are usually under the "Organizer"'s control 🫶
servers MUST allow "Attendees" to make the following iCalendar data changes, as long as other restrictions still apply, like access privileges and preconditions:
- change their own
"PARTSTAT"iCalendar property parameter value. - add, modify, or remove any
"TRANSP"iCalendar properties. - add, modify, or remove any
"PERCENT-COMPLETE"iCalendar properties. - add, modify, or remove any
"COMPLETED"iCalendar properties. - add, modify, or remove any
"VALARM"iCalendar components. - add, modify, or remove the
"CALSCALE"iCalendar property within the top-level"VCALENDAR"component. - modify the
"PRODID"iCalendar property within the top-level"VCALENDAR"component. - add
"EXDATE"iCalendar properties and possibly remove components for overridden recurrence instances. - add, modify, or remove any
"CREATED","DTSTAMP", and"LAST-MODIFIED"iCalendar properties. - add, modify, or remove
"SCHEDULE-STATUS"iCalendar property parameters on"ATTENDEE"properties that have a"SCHEDULE-AGENT"parameter set to"CLIENT". - add new components to represent overridden recurrence instances, as long as the only changes to the recurrence instance follow the rules above.
the server MUST return an error with the CALDAV:allowed-attendee-scheduling-object-change precondition code (Section 3.2.4.4) when the "Attendee" tries to change the iCalendar data in a way the server forbids 🚫
3.2.2.2. Create 🌸
typically, an "Attendee" doesn't create scheduling object resources, because scheduling messages delivered to them on the server are automatically processed by the server and placed on one of their calendars (see Section 4) 🤷♀️ but sometimes a scheduling message gets delivered straight to the client (for example, via email [RFC6047]), and the "Attendee" might want to store it on the server 💜 in that case, the client creates a scheduling object resource in a calendar that belongs to the "Attendee". it can then set the "SCHEDULE-AGENT" iCalendar property parameter on all "ORGANIZER" iCalendar properties in the resource, which tells the server how to treat it 🧠 the value of the "SCHEDULE-AGENT" iCalendar property parameter MUST be the same on all "ORGANIZER" iCalendar properties.
+----------------+--------------------------------------------------+
| SCHEDULE-AGENT | Action |
+----------------+--------------------------------------------------+
| SERVER | The server will attempt to process changes to |
| (default) | the resource using the normal rules for attendee |
| | scheduling object resources. |
| | |
| CLIENT | The server does no special processing of the |
| | resource. The client is assumed to be handling |
| | "Attendee" replies, etc. |
| | |
| NONE | The server does no special processing of the |
| | resource. |
+----------------+--------------------------------------------------+the "SCHEDULE-STATUS" iCalendar property parameters get added or changed on the "ORGANIZER" iCalendar properties in the scheduling object resource being created, as described in Section 7.3, with the value set as described in Section 3.2.9 🦋
3.2.2.3. Modify
Okay bestie, so this is the part where an "Attendee" changes an event that lives on the server. 🦋 The server's reaction depends on the SCHEDULE-AGENT parameter on the "ORGANIZER" properties, and I made you a little table because it's giving clarity 💅
+----------------+--------------------------------------------------+
| SCHEDULE-AGENT | Action |
+----------------+--------------------------------------------------+
| SERVER | The server will attempt to process the update |
| (default) | using the behavior listed below. |
| | |
| CLIENT | The server does no special processing of the |
| | resource. The client is assumed to be handling |
| | any "Attendee" replies, etc. |
| | |
| NONE | The server does no special processing of the |
| | resource. |
+----------------+--------------------------------------------------+So the server is gonna compare the new scheduling object resource with the old one to figure out what actually changed 🔍 no cap, this is the detective part ✨
If the "Attendee" changes one or more PARTSTAT values on any component, or adds an overridden component with a changed PARTSTAT property, then the server MUST deliver an iTIP REPLY scheduling message to the "Organizer" so they know the new participation status 🎀
If the "Attendee" adds an EXDATE value to effectively remove a recurrence instance, the server MUST deliver an iTIP REPLY scheduling message to the "Organizer" saying the "Attendee" has declined that instance 🙈 bye bye instance 💀
SCHEDULE-STATUS parameters get added or changed on the "ORGANIZER" properties in the scheduling object resource being modified, as described in Section 7.3, with the value set as described in Section 3.2.9 🌸 Because of this, the updated calendar object resource will be different from the calendar data that was sent in the HTTP request. So, lowkey, clients MAY reload the calendar data from the server to get the new server-generated state info 🫶
3.2.2.4. Remove
When an "Attendee" removes a scheduling object resource, the server's behavior depends on the SCHEDULE-AGENT parameter on the "ORGANIZER" properties. Same vibe as before, just with removal 🧚
+----------------+--------------------------------------------------+
| SCHEDULE-AGENT | Action |
+----------------+--------------------------------------------------+
| SERVER | The server will attempt to process the removal, |
| (default) | taking into account any "Schedule-Reply" request |
| | header as per Section 8.1. |
| | |
| CLIENT | The server does no special processing of the |
| | resource. The client is assumed to be handling |
| | any "Attendee" replies, etc. |
| | |
| NONE | The server does no special processing of the |
| | resource. |
+----------------+--------------------------------------------------+3.2.3. HTTP Methods
Now we're talking about how HTTP [RFC2616] and WebDAV [RFC4918] methods hit a scheduling object resource and trigger the create, modify, or remove stuff we just covered 🌈 The restrictions in [RFC4791] still apply on top of everything here, so don't forget those 💜
3.2.3.1. PUT
When the server gets a PUT request, it MUST run the following operations, as long as all the appropriate preconditions are met ✨
+------------------------+--------------------------+---------------+
| Existing Destination | Resulting Destination | Server |
| Resource | Resource | Operation |
+------------------------+--------------------------+---------------+
| None | Calendar object resource | None |
| | | |
| None | Scheduling object | Create |
| | resource | |
| | | |
| Calendar object | Calendar object resource | None |
| resource | | |
| | | |
| Calendar object | Scheduling object | Create |
| resource | resource | |
| Scheduling object | Calendar object resource | Remove |
| resource | | |
| | | |
| Scheduling object | Scheduling object | Modify |
| resource | resource | |
+------------------------+--------------------------+---------------+3.2.3.2. DELETE
When the server gets a DELETE request aimed at a scheduling object resource, it MUST execute the Remove operation 💅
When the server gets a DELETE request aimed at a calendar collection, it MUST execute the Remove operation on every scheduling object resource inside that calendar collection 🍓
3.2.3.3. COPY
When the server gets a COPY request, it MUST run the following operations based on the source and destination collections in the request 🦋
+-----------------------+------------------------+------------------+
| Source Collection | Destination Collection | Server Operation |
+-----------------------+------------------------+------------------+
| Non-calendar | Non-calendar | None |
| collection | collection | |
| | | |
| Non-calendar | Calendar collection | (1) |
| collection | | |
| | | |
| Calendar collection | Non-calendar | None |
| | collection | |
| | | |
| Calendar collection | Calendar collection | (2) |
+-----------------------+------------------------+------------------+Note (1): The rules in Section 3.2.3.1 are applied for the destination of the COPY request.
Note (2): The server MAY reject this as per Section 3.2.4.1; otherwise, None.
The behavior of a COPY request on a calendar collection is undefined 🫠 so that's a no-go zone, babe 🚫
3.2.3.4. MOVE
When the server gets a MOVE request, it MUST run the following operations based on the source and destination collections in the request 🌸
+-----------------------+------------------------+------------------+
| Source Collection | Destination Collection | Server Operation |
+-----------------------+------------------------+------------------+
| Non-calendar | Non-calendar | None |
| collection | collection | |
| | | |
| Non-calendar | Calendar collection | (1) |
| collection | | |
| | | |
| Calendar collection | Non-calendar | (2) |
| | collection | |
| | | |
| Calendar collection | Calendar collection | None |
+-----------------------+------------------------+------------------+Note (1): The rules in Section 3.2.3.1 are applied for the destination of the MOVE request.
Note (2): The rules in Section 3.2.3.2 are applied for the source of the MOVE request.
The behavior of a MOVE request on a calendar collection is undefined 🙃 same energy as COPY, not gonna touch it 🙅♀️
3.2.4. Additional Method Preconditions
This spec defines method preconditions (see Section 16 of WebDAV [RFC4918]) on top of the ones in [RFC4791], so error responses can be machine-parseable 🤖 very organized, very iconic 👑
3.2.4.1. CALDAV:unique-scheduling-object-resource Precondition
Name: unique-scheduling-object-resource
Namespace: urn:ietf:params:xml:ns:caldav
Apply to: PUT, COPY, and MOVE
Use with: 403 Forbidden
Purpose: (precondition) -- Servers MAY reject requests to create a scheduling object resource with an iCalendar UID property value that's already being used by another scheduling object resource owned by the same user in other calendar collections. Servers SHOULD report the URL of the scheduling object resource already using that same UID value in the DAV:href element 🔍
Definition:
<!ELEMENT unique-scheduling-object-resource (DAV:href?)>Example:
<C:unique-scheduling-object-resource xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:href>/home/bernard/calendars/personal/abc123.ics</D:href>
</C:unique-scheduling-object-resource>3.2.4.2. CALDAV:same-organizer-in-all-components Precondition
Name: same-organizer-in-all-components
Namespace: urn:ietf:params:xml:ns:caldav
Apply to: PUT, COPY, and MOVE
Use with: 403 Forbidden
Purpose: (precondition) -- All the calendar components in a scheduling object resource MUST contain the same ORGANIZER property value when present 🎀
Definition:
<!ELEMENT same-organizer-in-all-components EMPTY>3.2.4.3. CALDAV:allowed-organizer-scheduling-object-change Precondition
Name: allowed-organizer-scheduling-object-change
Namespace: urn:ietf:params:xml:ns:caldav
Apply to: PUT, COPY, and MOVE
Use with: 403 Forbidden
Purpose: (precondition) -- Servers MAY put restrictions on what an "Organizer" is allowed to change. For example, servers MAY stop the "Organizer" from setting the PARTSTAT parameter to anything other than NEEDS-ACTION if the matching ATTENDEE property has the SCHEDULE-AGENT parameter set to SERVER, or doesn't have the SCHEDULE-AGENT parameter at all. See Section 3.2.1. 🧐
Definition:
<!ELEMENT allowed-organizer-scheduling-object-change EMPTY>3.2.4.4. CALDAV:allowed-attendee-scheduling-object-change Precondition
Name: allowed-attendee-scheduling-object-change
Namespace: urn:ietf:params:xml:ns:caldav
Apply to: PUT, COPY, and MOVE
Use with: 403 Forbidden
Purpose: (precondition) -- Servers MAY put restrictions on what an "Attendee" is allowed to change, subject to the allowed changes in Section 3.2.2.1. 💖
Definition:
<!ELEMENT allowed-attendee-scheduling-object-change EMPTY>3.2.5. DTSTAMP and SEQUENCE Properties 🎀
okay bestie, so the server MUST make sure a "DTSTAMP" iCalendar property is there and set to the UTC time the scheduling message was generated 🕰️ (iCalendar wants this, no cap) ✨
and the server MUST also make sure the "SEQUENCE" iCalendar property value gets updated for each type of scheduling operation, following iTIP [RFC5546] 🔁
3.2.6. Restrict Recurrence Instances Sent to "Attendees" 🦋
okay this one is giving privacy, and I'm obsessed 🙈 Servers MUST make sure that when they deliver scheduling messages for recurring calendar components, "Attendees" only get info about the recurrence instances that explicitly include them as an "Attendee" 💅
let's say an "Attendee" is only invited to one instance of a recurring event. The organizer scheduling object resource ends up with an overridden instance as its own separate calendar component. That component has the "ATTENDEE" property pointing at the "one-off" "Attendee". That "Attendee" doesn't show up in any other calendar component in the scheduling object resource, and any scheduling messages delivered to them only talk about this overridden instance 🧚
now the other way around: an "Attendee" gets excluded from one instance of a recurring event. This time the organizer scheduling object resource has an overridden instance whose "ATTENDEE" list leaves out the excluded "Attendee". The scheduling messages delivered to that "Attendee" won't mention the overridden instance at all. Instead, they include an "EXDATE" property in the "master" component that defines the recurrence set 💀
3.2.7. Forcing the Server to Send a Scheduling Message 📬
so the iCalendar property parameter "SCHEDULE-FORCE-SEND", which you can read about in Section 7.2, is the move when a calendar user wants the server to send a scheduling message to an "Attendee" or the "Organizer" even though the server wouldn't normally send one 🙌
for example, an "Organizer" could use this parameter to ask an "Attendee" who previously declined an invite to reconsider their participation status, and they wouldn't have to modify the event to do it 🫶
3.2.8. "Attendee" Participation Status 💜
this section adds some extra rules for handling the "PARTSTAT" property parameter when the "SCHEDULE-AGENT" property parameter on the matching "ATTENDEE" property is set to "SERVER" or isn't there at all 👑
a reschedule happens when any "DTSTART", "DTEND", "DURATION", "DUE", "RRULE", "RDATE", or "EXDATE" property changes in a calendar component in a way that messes with existing recurrence instances. The table below shows how that plays out. so basically, servers MUST reset the "PARTSTAT" property parameter value of every "ATTENDEE" property, except the one for the "Organizer", back to "NEEDS-ACTION" every time a calendar component change causes any instance to get rescheduled 🔄
+-----------+-------------------------------------------------------+
| Property | Server Action |
+-----------+-------------------------------------------------------+
| DTSTART, | Any change to these properties results in "PARTSTAT" |
| DTEND, | being set to "NEEDS-ACTION". |
| DURATION, | |
| DUE | |
| | |
| RRULE | A change to or addition of this property that results |
| | in the addition of new recurring instances or a |
| | change in time for existing recurring instances |
| | results in "PARTSTAT" being reset to "NEEDS-ACTION" |
| | on each affected component. |
| | |
| RDATE | A change to or addition of this property that results |
| | in the addition of new recurring instances or a |
| | change in time for existing recurring instances |
| | results in "PARTSTAT" being reset to "NEEDS-ACTION" |
| | on each affected component. |
| | |
| EXDATE | A change to or removal of this property that results |
| | in the reinstatement of recurring instances results |
| | in "PARTSTAT" being set to "NEEDS-ACTION" on each |
| | affected component. |
+-----------+-------------------------------------------------------+the server MAY let the "Organizer's" client flip an "Attendee's" "PARTSTAT" back to "NEEDS-ACTION" at any other time 🪄 (like when the "LOCATION" value changes, and the "Organizer" wants to re-invite the "Attendees" who might be affected by it) 📍
3.2.9. Schedule Status Values 📊
when you schedule with an "Attendee", there are two kinds of status info that can come back during the operation 👀 The first is a "delivery" status, which tells you whether the scheduling message from the "Organizer" to the "Attendee" got delivered, or how delivery is going right now. The second is a "reply" status, which matches the "Attendee's" own "REQUEST-STATUS" info from the reply scheduling message that gets sent back to the "Organizer" 💖
it's kinda the same in reverse. When an "Attendee" replies to the "Organizer", there's "delivery" status info for the message sent to the "Organizer". But the "Organizer" doesn't send any "REQUEST-STATUS" back, so there's no "reply" status equivalent for scheduling messages to "Attendees" 🙃
the "delivery" status info lives on an "ORGANIZER" or "ATTENDEE" iCalendar property and gets passed along in the "SCHEDULE-STATUS" property parameter value (Section 7.3). The status code value for "delivery" status can be one of these 📦
+----------+--------------------------------------------------------+
| Delivery | Description |
| Status | |
| Code | |
+----------+--------------------------------------------------------+
| 1.0 | The scheduling message is pending. That is, the |
| | server is still in the process of sending the message. |
| | The status code value can be expected to change once |
| | the server has completed its sending and delivery |
| | attempts. |
| | |
| 1.1 | The scheduling message has been successfully sent. |
| | However, the server does not have explicit information |
| | about whether the scheduling message was successfully |
| | delivered to the recipient. This state can occur with |
| | "store and forward" style scheduling protocols such as |
| | iMIP [RFC6047] (iTIP using email). |
| | |
| 1.2 | The scheduling message has been successfully |
| | delivered. |
| | |
| 3.7 | The scheduling message was not delivered because the |
| | server did not recognize the calendar user address as |
| | a valid calendar user. Note that this code applies to |
| | both "Organizer" and "Attendee" calendar user |
| | addresses. |
| | |
| 3.8 | The scheduling message was not delivered due to |
| | insufficient privileges. Note that this code applies |
| | to privileges granted by both the "Organizer" and |
| | "Attendee" calendar users. |
| | |
| 5.1 | The scheduling message was not delivered because the |
| | server could not complete delivery of the message. |
| | This is likely due to a temporary failure, and the |
| | originator can try to send the message again at a |
| | later time. |
| | |
| 5.2 | The scheduling message was not delivered because the |
| | server was not able to find a way to deliver the |
| | message. This is likely a permanent failure, and the |
| | originator ought not try to send the message again, at |
| | least without verifying/correcting the calendar user |
| | address of the recipient. |
| | |
| 5.3 | The scheduling message was not delivered and was |
| | rejected because scheduling with that recipient is not |
| | allowed. This is likely a permanent failure, and the |
| | originator ought not try to send the message again. |
+----------+--------------------------------------------------------+the "reply" status code can be any of the valid iTIP [RFC5546] "REQUEST-STATUS" values ✅
okay, the new 1.xx "REQUEST-STATUS" codes are brand new 🌱 This spec tweaks item (2) of Section 3.6 of [RFC5546] by adding this restriction:
For a 1.xx code, all components MUST have exactly the same code.
here's how the new 1.xx codes are defined 💅
3.2.9.1. Status Code 1.0 ⏳
Status Code: 1.0
Status Description: Pending.
Status Exception Data: None.
Description: Delivery of the iTIP message is pending.3.2.9.2. Status Code 1.1 📤
Status Code: 1.1
Status Description: Sent.
Status Exception Data: None.
Description: The iTIP message has been sent, though no information
about successful delivery is known.3.2.9.3. Status Code 1.2 🎉
Status Code: 1.2
Status Description: Delivered.
Status Exception Data: None.
Description: The iTIP message has been sent and delivered.3.2.10. Avoiding Conflicts when Updating Scheduling Object Resources 🎀
okay so scheduling object resources on the server can change super often 🔄, because every time an "Attendee" changes their participation status, the server has to update the "Organizer" and refresh everybody else's copy. that can lead to an "inconsequential" change to a calendar user's data, one that doesn't directly affect the user's own participation status 🙈. when that happens, clients have to reload calendar data and reconcile it with changes other calendar users are making, and nobody wants that. so the server can instead merge calendar data changes from a client with changes made by a scheduling operation that some other calendar user carried out ✨.
this spec introduces a new WebDAV resource property CALDAV:schedule-tag, with a matching response header called Schedule-Tag, plus a new If-Schedule-Tag-Match request header. together they let client changes merge cleanly with server changes when those server changes came from an "inconsequential" scheduling message update (one that just updates the "Attendees'" status info because another "Attendee" replied) 💅.
Servers MUST automatically resolve conflicts with "inconsequential" changes done to scheduling object resources when the If-Schedule-Tag-Match request header is specified. The If-Schedule-Tag-Match request header applies only to the Request-URI, and not to the destination of a COPY or MOVE 🧚.
A response to any successful GET or PUT request targeting a scheduling object resource MUST include a Schedule-Tag response header, with the value set to the same value as the CALDAV:schedule-tag WebDAV property of the resource 🍓.
A response to any successful COPY or MOVE request that specifies a Destination request header targeting a scheduling object resource MUST include a Schedule-Tag response header, with the value set to the same value as the CALDAV:schedule-tag WebDAV property of the destination resource 💜.
Clients SHOULD use the If-Schedule-Tag-Match header on requests that update scheduling object resources, instead of HTTP ETag-based precondition tests (e.g., If-Match). Normal ETag-based precondition tests are used in all other cases, e.g., for synchronization 🫶.
the CALDAV:schedule-tag property changes according to these rules 👑:
- For an "Organizer's" copy of a scheduling object resource:
- The server MUST NOT change the
CALDAV:schedule-tagproperty value when the scheduling object resource is updated as the result of automatically processing a scheduling message reply from an "Attendee". For instance, when an "Attendee" replies to the "Organizer", theCALDAV:schedule-tagproperty stays unchanged after the server automatically updates the "Organizer's" scheduling object resource with the "Attendee's" new participation status 🌸. - The server MUST change the
CALDAV:schedule-tagproperty value when the scheduling object resource is changed directly via an HTTP request (e.g., PUT, COPY, or MOVE) 🔥.
- The server MUST NOT change the
- For an "Attendee's" copy of a scheduling object resource:
- The server MUST change the
CALDAV:schedule-tagproperty value when the scheduling object resource is changed as the result of processing a scheduling message update from an "Organizer" that contains changes other than just the participation status of "Attendees" 🌈. - The server MUST NOT change the
CALDAV:schedule-tagproperty value when the scheduling object resource is changed as the result of processing a scheduling message update from an "Organizer" that only specifies changes in the participation status of "Attendees". For instance, when "Attendee" "A" replies to "Organizer" "O", and "Attendee" "B" receives a scheduling message update from "Organizer" "O" with the new participation status of "Attendee" "A", theCALDAV:schedule-tagproperty of "Attendee" "B"'s scheduling object resource would remain the same ⭐. - The server MUST change the
CALDAV:schedule-tagproperty value when the scheduling object resource is changed directly via an HTTP request (e.g., PUT, COPY, or MOVE) 🦋.
- The server MUST change the
3.2.10.1. PUT 💖
Clients MAY use the If-Schedule-Tag-Match request header to do a PUT request that makes sure "inconsequential" changes on the server don't cause a precondition error ✨. the value of the request header is set to the last Schedule-Tag value received for the resource being modified. If the value of the If-Schedule-Tag-Match header matches the current value of the CALDAV:schedule-tag property, the server MUST take any "ATTENDEE" property changes for all "Attendees" other than the owner of the scheduling object resource and apply those to the new resource being stored. Otherwise, the server MUST fail the request with a 412 Precondition Failed status code 😭.
3.2.10.2. DELETE, COPY, or MOVE 🌷
Clients MAY use the If-Schedule-Tag-Match request header to do a DELETE, COPY, or MOVE request that makes sure "inconsequential" changes on the server don't cause a precondition error 🍭. the value of the request header is set to the last Schedule-Tag value received for the resource being deleted. If the value of the If-Schedule-Tag-Match header matches the current value of the CALDAV:schedule-tag property, the server performs the normal DELETE, COPY, or MOVE request processing for the resource. Otherwise, the server MUST fail the request with a 412 Precondition Failed status code 💀.
4. Processing Incoming Scheduling Messages ✨
scheduling operations can deliver a scheduling message into an "Organizer's" or "Attendee's" scheduling Inbox collection 📬. Servers MUST automatically process incoming scheduling messages using the rules defined by [RFC5546], creating or updating the matching scheduling object resources on calendars owned by the owner of the scheduling Inbox collection. The message also gets stored in the scheduling Inbox collection as a heads-up that a scheduling operation happened 👀. clients usually remove scheduling messages from the scheduling Inbox collection once the calendar user has acknowledged the change 🧹.
The server MUST take into account privileges on the scheduling Inbox collection when processing incoming scheduling messages, to decide whether the scheduling message can be delivered. Privileges on calendars that contain a matching scheduling object resource are not considered in this case. (Basically, a scheduling message from another user can change resources in calendar collections that the other user wouldn't normally be allowed to read or write 😳.) Additionally, servers MUST take into account any scheduling Inbox collection preconditions (see Section 2.2) when delivering the scheduling message, and MUST take into account the similar preconditions on any calendar collection that contains, or would contain, the corresponding scheduling object resource 🔐.
4.1. Processing "Organizer" Requests, Additions, and Cancellations 📝
For a scheduling message sent by an "Organizer", the server first tries to find a matching scheduling object resource belonging to the "Attendee". If no matching scheduling object resource exists, the server treats the scheduling message as a new message. Otherwise, it's treated as an update 🔍.
If it's a new message, the server processes the scheduling message and creates a new scheduling object resource as per Section 4.3 🌱.
If it's an update, the server processes the scheduling message and updates the matching scheduling object resource belonging to the "Attendee" so it reflects the changes the "Organizer" sent 🔄.
In each case, the scheduling message MUST only appear in the "Attendee's" scheduling Inbox collection once all automatic processing has been done ⏳.
4.2. Processing "Attendee" Replies 💌
For a scheduling message reply sent by an "Attendee", the server first locates the matching scheduling object resource belonging to the "Organizer". If that scheduling object resource can't be found, the server SHOULD ignore the scheduling message 🙃.
The server MUST then update the PARTSTAT iCalendar property parameter value of each ATTENDEE iCalendar property in the scheduling object resource so it matches the changes in the reply. (This also covers the fact that an "Attendee" could have created a new overridden iCalendar component to show a different participation status on one or more instances of a recurring event 🔁.)
The server MUST also update or add the SCHEDULE-STATUS property parameter on each matching ATTENDEE iCalendar property, and set its value to that of the REQUEST-STATUS property in the reply, or to 2.0 if REQUEST-STATUS isn't present (also taking recurrence instances into account 🧠). If there are multiple REQUEST-STATUS properties in the reply, the SCHEDULE-STATUS property parameter value is set to a comma-separated list of status codes, with one from each REQUEST-STATUS property 📋.
The server SHOULD send scheduling messages to all the other "Attendees" about the change in participation status of the "Attendee" who replied, subject to the recurrence requirements of Section 3.2.6 📣.
The scheduling message MUST only appear in the "Organizer's" scheduling Inbox collection once all automatic processing has been done 🎉.
4.3. Default Calendar Collection 🏡
The server processes scheduling messages received for an "Attendee" by creating a new scheduling object resource in a calendar collection belonging to the "Attendee", when one doesn't already exist. A calendar user who is an "Attendee" in a scheduling operation MUST have at least one valid calendar collection available. If there's no valid calendar collection, the server MUST reject the attempt to deliver the scheduling message to the "Attendee" 🚫.
Servers MAY provide support for a default calendar collection, which is the calendar collection where new scheduling object resources get created 🌟. The CALDAV:schedule-default-calendar-URL WebDAV property, which can be present on the scheduling Inbox collection of a calendar user, specifies whether this calendar user has a default calendar collection. See Section 9.2 📍.
Servers SHOULD create new scheduling object resources in the default calendar collection, if the CALDAV:schedule-default-calendar-URL WebDAV property is set 🗂️.
Servers MAY allow clients to change the default calendar collection by changing the value of the CALDAV:schedule-default-calendar-URL WebDAV property on the scheduling Inbox collection. However, the server MUST ensure that any new value for that property refers to a valid calendar collection belonging to the owner of the scheduling Inbox collection 🛡️.
Servers MUST reject any attempt to delete the default calendar collection 🙅♀️.
4.3.1. Additional Method Preconditions 🧾
This specification defines additional method preconditions (see Section 16 of WebDAV [RFC4918]) to provide machine-parseable information in error responses 🤖.
4.3.1.1. CALDAV:default-calendar-needed Precondition 🎀
Okay so this one is for when someone tries to delete the calendar that's currently pointed to by the CALDAV:schedule-default-calendar-URL property 🙈 Or they try to remove that property from the scheduling Inbox collection on a server that doesn't let anyone do that. Bestie, it's a whole no-go zone 💀
- Name:
default-calendar-needed - Namespace:
urn:ietf:params:xml:ns:caldav - Apply to:
DELETE - Use with:
403 Forbidden - Purpose: (precondition) The client attempted to delete the calendar collection currently referenced by the CALDAV:schedule-default-calendar-URL property, or attempted to remove the CALDAV:schedule-default-calendar-URL property on the scheduling Inbox collection on a server that doesn't allow such operations.
Definition:
<!ELEMENT default-calendar-needed EMPTY>4.3.1.2. CALDAV:valid-schedule-default-calendar-URL Precondition 🌸
This one is about trying to set the CALDAV:schedule-default-calendar-URL property to a DAV:href that doesn't point at a valid calendar collection. Not it 🙅♀️ Also, a heads up: servers that don't let clients change that property at all will just throw the DAV:cannot-modify-protected-property precondition from Section 16 of WebDAV [RFC4918] instead. Same vibe, different outfit 💅
- Name:
valid-schedule-default-calendar-URL - Namespace:
urn:ietf:params:xml:ns:caldav - Apply to:
PROPPATCH - Use with:
403 Forbidden - Purpose: (precondition) The client attempted to set the CALDAV:schedule-default-calendar-URL property to a DAV:href element that doesn't reference a valid calendar collection. Note: Servers that do not allow clients to change the CALDAV:schedule-default-calendar-URL property would simply return the DAV:cannot-modify-protected-property precondition defined in Section 16 of WebDAV [RFC4918].
Definition:
<!ELEMENT valid-schedule-default-calendar-URL EMPTY>5. Request for Busy Time Information 🔥
Okay, big moment: you can figure out the busy time of one or more calendar users by sending a POST request to the scheduling Outbox collection of the person asking for the info. That person is the "Organizer" ✨ The request body MUST contain a "VFREEBUSY" calendar component with the "METHOD" iCalendar property set to the value "REQUEST", as described in Section 3.3.2 of iTIP [RFC5546]. The resource at the Request-URI MUST be a resource collection of type CALDAV:schedule-outbox (Section 2.1). And the "ORGANIZER" property value in the "VFREEBUSY" component MUST match one of the calendar user addresses of the Outbox collection's owner. No lying about who you are 🫶
The response to a busy time request that covers one or more calendar users MUST be an XML document whose root element is CALDAV:schedule-response. That root element MUST contain one CALDAV:response element for each calendar user. Each of those elements has child elements saying which calendar user it's for, their scheduling status, any error codes, and an optional description. If the busy time request works out, each calendar user also gets a CALDAV:calendar-data element holding the actual busy time info, which is an iCalendar "VFREEBUSY" component 🦋 Check Section 10 for the details on those child elements, and Appendix B.5 for an example busy time request and response.
5.1. Status Codes 💖
Here's the cheat sheet of the most common status codes for this method. Heads up though, clients need to be ready for other 2/3/4/5xx status codes too, because the internet is chaotic 😭
200 (OK)- The command succeeded.204 (No Content)- The command succeeded.400 (Bad Request)- The client has provided an invalid scheduling message.403 (Forbidden)- The client cannot submit a scheduling message to the specified Request-URI.404 (Not Found)- The URL in the Request-URI was not present.423 (Locked)- The specified resource is locked, and the client either is not a lock owner or the lock type requires a lock token to be submitted and the client did not submit it.
5.2. Additional Method Preconditions 🧚
These are existing preconditions that get reused for the POST method on an Outbox collection, so no need to reinvent the wheel:
DAV:need-privileges[RFC3744]CALDAV:supported-calendar-data[RFC4791]CALDAV:valid-calendar-data[RFC4791]CALDAV:max-resource-size[RFC4791]
And these are the new method preconditions for the POST method on an Outbox collection 👑
5.2.1. CALDAV:valid-scheduling-message Precondition ⭐
- Name:
valid-scheduling-message - Namespace:
urn:ietf:params:xml:ns:caldav - Apply to:
POST - Use with:
400 Bad Request - Purpose: (precondition) The resource submitted in the POST request MUST obey all the restrictions specified in Section 3.3.2 of iTIP [RFC5546].
Definition:
<!ELEMENT valid-scheduling-message EMPTY>5.2.2. CALDAV:valid-organizer Precondition 🍓
- Name:
valid-organizer - Namespace:
urn:ietf:params:xml:ns:caldav - Apply to:
POST - Use with:
403 Forbidden - Purpose: (precondition) The "ORGANIZER" property value in the POST request's scheduling message MUST match one of the calendar user addresses of the owner of the scheduling Outbox collection being targeted by the request.
Definition:
<!ELEMENT valid-organizer EMPTY>6. Scheduling Privileges 🌈
New scheduling privileges get defined in this section, and they're giving main character energy 👑 All the scheduling privileges MUST be non-abstract and MUST appear in the DAV:supported-privilege-set property of the scheduling Outbox and Inbox collections they're defined on. The tables in Appendix A show which scheduling methods (like "REQUEST", "REPLY", etc.) each privilege controls, so go check those out ✨
6.1. Privileges on Scheduling Inbox Collections 🦋
This section defines new WebDAV Access Control List (ACL) [RFC3744] privileges for scheduling Inbox collections. They decide whether the calendar user who "owns" the Inbox is cool with receiving scheduling messages from a certain calendar user. So calendar users get to pick who can schedule with them. Boundaries, iykyk 🙅♀️
Here's a detail that's easy to miss: when a scheduling message gets delivered, a scheduling object resource gets created in the Inbox, and that's not all. A new scheduling object resource might also get created, or an existing one updated, in one of the calendar user's calendars. In that case, whether that calendar resource can be created or updated is controlled by the privileges on the scheduling Inbox collection 🧠
The privileges in this section get ignored if they're applied to anything other than a scheduling Inbox collection.
6.1.1. CALDAV:schedule-deliver Privilege 💜
CALDAV:schedule-deliver is an aggregate privilege, as per Section 6.3.
Definition:
<!ELEMENT schedule-deliver EMPTY>6.1.2. CALDAV:schedule-deliver-invite Privilege 💌
The CALDAV:schedule-deliver-invite privilege controls the processing and delivery of scheduling messages coming from an "Organizer".
Definition:
<!ELEMENT schedule-deliver-invite EMPTY>6.1.3. CALDAV:schedule-deliver-reply Privilege 💬
The CALDAV:schedule-deliver-reply privilege controls the processing and delivery of scheduling messages coming from an "Attendee".
Definition:
<!ELEMENT schedule-deliver-reply EMPTY>6.1.4. CALDAV:schedule-query-freebusy Privilege 🫧
The CALDAV:schedule-query-freebusy privilege controls freebusy requests aimed at the owner of the scheduling Inbox collection.
Definition:
<!ELEMENT schedule-query-freebusy EMPTY>6.2. Privileges on Scheduling Outbox Collections 🎀
This section defines new WebDAV ACL [RFC3744] privileges for scheduling Outbox collections. They decide which calendar users are allowed to send scheduling messages on behalf of the calendar user who "owns" the Outbox. This is how calendar users pick who can act for them, like an assistant handling their boss's schedule 💅
The privileges in this section get ignored if they're applied to anything other than a scheduling Outbox collection.
6.2.1. CALDAV:schedule-send Privilege 🌟
CALDAV:schedule-send is an aggregate privilege, as per Section 6.3.
Definition:
<!ELEMENT schedule-send EMPTY>6.2.2. CALDAV:schedule-send-invite Privilege 📨
The CALDAV:schedule-send-invite privilege controls the sending of scheduling messages by "Organizers".
Users who've been granted the DAV:bind privilege on a calendar collection, or the DAV:write privilege on scheduling object resources, also need the CALDAV:schedule-send-invite privilege on the scheduling Outbox collection of the owner of that calendar collection or scheduling object resource. Only then can they create, modify, or delete scheduling object resources in a way that makes the CalDAV server deliver scheduling messages to "Attendees" 🙌
Definition:
<!ELEMENT schedule-send-invite EMPTY>6.2.3. CALDAV:schedule-send-reply Privilege 🥰
The CALDAV:schedule-send-reply privilege controls the sending of scheduling messages by "Attendees".
Users who've been granted the DAV:bind privilege on a calendar collection, or the DAV:write privilege on scheduling object resources, also need the CALDAV:schedule-send-reply privilege on the scheduling Outbox collection of the owner of that calendar collection or scheduling object resource. Then they can create, modify, or delete scheduling object resources in a way that makes the CalDAV server deliver scheduling message replies to the "Organizer" 💫
Definition:
<!ELEMENT schedule-send-reply EMPTY>6.2.4. CALDAV:schedule-send-freebusy Privilege 🫶
The CALDAV:schedule-send-freebusy privilege controls the use of the POST method to submit scheduling messages that specify the scheduling method "REQUEST" with a "VFREEBUSY" calendar component.
Definition:
<!ELEMENT schedule-send-freebusy EMPTY>6.3. Aggregation of Scheduling Privileges 🧩
Server implementations MUST aggregate the scheduling privileges like this:
DAV:allcontainsCALDAV:schedule-deliverandCALDAV:schedule-send;CALDAV:schedule-delivercontainsCALDAV:schedule-deliver-invite,CALDAV:schedule-deliver-reply, andCALDAV:schedule-query-freebusy;CALDAV:schedule-sendcontainsCALDAV:schedule-send-invite,CALDAV:schedule-send-reply, andCALDAV:schedule-send-freebusy.
This diagram shows how the scheduling privileges get aggregated, based on those rules 🌸
[DAV:all] (aggregate)
|
+-- [CALDAV:schedule-deliver] (aggregate)
| |
| +-- [CALDAV:schedule-deliver-invite]
| +-- [CALDAV:schedule-deliver-reply]
| +-- [CALDAV:schedule-query-freebusy]
|
+-- [CALDAV:schedule-send] (aggregate)
|
+-- [CALDAV:schedule-send-invite]
+-- [CALDAV:schedule-send-reply]
+-- [CALDAV:schedule-send-freebusy]7. Additional iCalendar Property Parameters ✨
This specification defines additional iCalendar property parameters to support the CalDAV scheduling extensions. Little new tools for the scheduling toolkit 🧰
Hold up, bestie, this is the good stuff 🦋
Parameters are the little tags you hang on a property, and these three are iconic for deciding who's responsible for sending the invites, replies and status updates. Let's get into it 💅
7.1. Schedule Agent Parameter ✨
Parameter Name: SCHEDULE-AGENT 🎀
Purpose: this one tells everyone which agent is supposed to deliver scheduling messages to the matching "Organizer" or "Attendee". 💜
Format Definition: here's the exact shape, no cap:
scheduleagentparam = "SCHEDULE-AGENT" "="
("SERVER" ; The server handles scheduling
/ "CLIENT" ; The client handles scheduling
/ "NONE" ; No scheduling
/ x-name ; Experimental type
/ iana-token) ; Other IANA-registered type
;
; If the parameter is not present, its value defaults to SERVER.
; "x-name" and "iana-token" are defined in Section 3.1 of
; [RFC5545].Description: this parameter MAY be specified on "ORGANIZER" or "ATTENDEE" iCalendar properties. If it's missing, the value "SERVER" MUST be used as the default behavior. The value decides whether a scheduling operation on a server actually sends a scheduling message to the calendar user in that "ORGANIZER" or "ATTENDEE" property. When the value is "SERVER", or the parameter is absent, it's the server's job to send the scheduling message as part of a scheduling operation. When the value is "CLIENT", the client is handling the scheduling messages with the calendar user itself. When it's "NONE", no scheduling messages get sent to that calendar user. 🙈
Servers MUST NOT include this parameter in any scheduling messages they send as the result of a scheduling operation. 🚫
Clients MUST NOT include this parameter in any scheduling messages that they send themselves. 💅
The parameter value MUST be the same on every "ORGANIZER" property in a scheduling object resource. ✨
The parameter value MUST be the same on each "ATTENDEE" property whose values match in a scheduling object resource. 🦋
Servers and clients MUST treat x-name and iana-token values they don't recognize the same way they'd treat the "NONE" value. 💀
Example:
ORGANIZER;SCHEDULE-AGENT=SERVER:mailto:bernard@example.com
ATTENDEE;SCHEDULE-AGENT=NONE:mailto:cyrus@example.com7.2. Schedule Force Send Parameter 🌸
Parameter Name: SCHEDULE-FORCE-SEND 🎀
Purpose: this one forces a scheduling message to be sent to the calendar user named on the property. Main character energy 👑
Format Definition: the grammar, verbatim:
scheduleforcesendparam = "SCHEDULE-FORCE-SEND" "="
("REQUEST" ; Force a "REQUEST"
/ "REPLY" ; Force a "REPLY"
/ iana-token)
;
; "iana-token" is defined in Section 3.1 of [RFC5545]. Its value
; <hotpink>MUST</hotpink> be an IANA-registered iCalendar "METHOD" property value.Wait, I need to keep the key words in plain text exactly as they are, so let me restate that last line properly:
; "iana-token" is defined in Section 3.1 of [RFC5545]. Its value
; MUST be an IANA-registered iCalendar "METHOD" property value.Description: this parameter MAY be specified on "ATTENDEE" and "ORGANIZER" properties where "SCHEDULE-AGENT" is set to "SERVER" or isn't specified at all. It's used to force a server to send a scheduling message to a specific calendar user in situations where the server otherwise wouldn't bother, like when no change that deserves a new scheduling message happened on the scheduling object resource. An "Organizer" MAY put this parameter on an "ATTENDEE" property with the value "REQUEST" to force a "REQUEST" scheduling message to that "Attendee". An "Attendee" MAY put it on the "ORGANIZER" with the value "REPLY" to force a "REPLY" scheduling message to the "Organizer". 🔥
Servers MUST NOT preserve this property parameter in scheduling object resources, and they MUST NOT include it in any scheduling messages sent as the result of a scheduling operation. 🚫
Clients MUST NOT include this parameter in any scheduling messages that they send themselves. 💖
Servers MUST set the "SCHEDULE-STATUS" parameter of the "ATTENDEE" or "ORGANIZER" to 2.3 (that's "Success; invalid property parameter ignored", see Section 3.6 of [RFC5546]) when the "SCHEDULE-FORCE-SEND" parameter is set to an iana-token value they don't recognize. 🥺
Example:
ORGANIZER;SCHEDULE-FORCE-SEND=REPLY:mailto:cyrus@example.com
ATTENDEE;SCHEDULE-FORCE-SEND=REQUEST:mailto:bernard@example.com7.3. Schedule Status Parameter 🍓
Parameter Name: SCHEDULE-STATUS 🎀
Purpose: this one records the status codes from processing the most recent scheduling message sent to the matching "Attendee", or received from the matching "Organizer". 📬
Format Definition: here's the grammar:
schedulestatusparam = "SCHEDULE-STATUS" "="
( statcode
/ DQUOTE statcode *("," statcode) DQUOTE)
;
; "statcode" is defined in Section 3.8.8.3 of [RFC5545]. The
; value is a single "statcode" or a comma-separated list of
; "statcode" values.Description: this parameter MAY be specified on the "ATTENDEE" and "ORGANIZER" properties. 🌈
Servers MUST only add or change this parameter on any "ATTENDEE" properties for calendar users who were sent a scheduling message through a scheduling operation. Clients SHOULD NOT change or remove this parameter if the server provided it. When the client is handling the scheduling, the client MAY add, change, or remove this parameter to show the last scheduling message status it got. ✨
Servers MUST add this parameter to any "ORGANIZER" properties for calendar users who were sent a scheduling message reply by an "Attendee" through a scheduling operation. Clients SHOULD NOT change or remove this parameter if the server provided it. When the client is handling the scheduling, the client MAY add, change, or remove this parameter to show the last scheduling message status it got. 💅
Servers MUST NOT include this parameter in any scheduling messages sent as the result of a scheduling operation. 🚫
Clients MUST NOT include this parameter in any scheduling messages that they send themselves. 🫶
Values for this property parameter are described in Section 3.2.9. 🦋
Example:
ATTENDEE;SCHEDULE-STATUS="2.0":mailto:bernard@example.com
ATTENDEE;SCHEDULE-STATUS="2.0,2.4":mailto:cyrus@example.com8. Additional Message Header Fields 💜
This specification defines additional HTTP request and response headers for use with CalDAV. Think of headers as the sticky notes on a request, and these are the new ones we get to use 🧚
8.1. Schedule-Reply Request Header 🌸
Schedule-Reply = "Schedule-Reply" ":" ("T" | "F")Example:
Schedule-Reply: FWhen an "Attendee" removes a scheduling object resource as per Section 3.2.2.4, and the Schedule-Reply header is set to "T" (true) or isn't present at all, the server MUST send an appropriate reply scheduling message with the "Attendee's" "PARTSTAT" iCalendar property parameter value set to "DECLINED" as part of its normal scheduling operation processing. 💀
When the Schedule-Reply header is set to "F" (false), the server MUST NOT send a scheduling message as part of its normal scheduling operation processing. 🙈
The Schedule-Reply request header is how a client tells a server whether a scheduling operation ought to happen when an "Attendee" deletes a scheduling object resource. In particular, it controls whether a reply scheduling message goes to the "Organizer" because of the removal. Sometimes unsolicited scheduling messages need to be quietly removed (or ignored) for security or privacy reasons, and this header lets the scheduling object resource be removed if that need comes up. 🔒
8.2. Schedule-Tag Response Header 🦋
The Schedule-Tag response header provides the current value of the CALDAV:schedule-tag property. The behavior of this response header is described in Section 3.2.10. ✨
All scheduling object resources MUST support the Schedule-Tag header. 💖
Schedule-Tag = "Schedule-Tag" ":" opaque-tag
; "opaque-tag" is defined in Section 3.11 of [RFC2616].Example:
Schedule-Tag: "12ab34-cd56ef"8.3. If-Schedule-Tag-Match Request Header 🍓
The If-Schedule-Tag-Match request header field is used with a method to make it conditional. Clients can set this header to the value returned in the Schedule-Tag response header, or the CALDAV:schedule-tag property, of a scheduling object resource previously retrieved from the server, so they don't overwrite "consequential" changes to the scheduling object resource. 🫶
All scheduling object resources MUST support the If-Schedule-Tag-Match header. 👑
If-Schedule-Tag-Match = "If-Schedule-Tag-Match" ":" opaque-tag
; "opaque-tag" is defined in Section 3.11 of [RFC2616].Example:
If-Schedule-Tag-Match: "12ab34-cd56ef"9. Additional WebDAV Properties 🌈
This specification defines the following new WebDAV properties for use with CalDAV. 🧚
9.1. CALDAV:schedule-calendar-transp Property 🎀
Name: schedule-calendar-transp
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: this decides whether the calendar object resources in a calendar collection count toward the owner's busy time information. ⭐
Protected: this property MAY be protected, and it SHOULD NOT be returned by a PROPFIND DAV:allprop request (as defined in Section 14.2 of [RFC4918]). 🔐
COPY/MOVE behavior: this property value SHOULD be kept during a MOVE operation, and SHOULD be copied and preserved in a COPY. 🌸
Description: this property SHOULD be defined on all calendar collections. If it's present, it holds one of two XML elements that say whether the calendar object resources in the collection ought to contribute to the owner's busy time. When the CALDAV:opaque element is used, all calendar object resources in the corresponding calendar collection MUST contribute to busy time, assuming access privileges and other iCalendar properties allow it. When the CALDAV:transparent XML element is used, the calendar object resources in the corresponding calendar collection MUST NOT contribute to busy time. 🦋
If this property isn't present on a calendar collection, then the default value CALDAV:opaque MUST be assumed. 💜
Definition:
<!ELEMENT schedule-calendar-transp (opaque | transparent)>
<!ELEMENT opaque EMPTY>
<!-- Affects busy time searches -->
<!ELEMENT transparent EMPTY>
<!-- Invisible to busy time searches -->Example:
<C:schedule-calendar-transp
xmlns:C="urn:ietf:params:xml:ns:caldav">
<C:opaque/>
</C:schedule-calendar-transp>9.2. CALDAV:schedule-default-calendar-URL Property 💖
- Name:
schedule-default-calendar-URL - Namespace:
urn:ietf:params:xml:ns:caldav - Purpose: okay so this one picks a default calendar for an "Attendee" 🧚, so brand-new scheduling object resources know where to land. ✨
- Protected: This property MAY be protected if the server can't change the default calendar, or if it doesn't support having one at all. 🔒
- COPY/MOVE behavior: It's only defined on a scheduling Inbox collection, and that collection can't be moved or copied. 🚫
- Description: This property MAY be defined on a scheduling Inbox collection. If it's there, it holds zero or one
DAV:hrefXML elements. When aDAV:hrefis present, its value is a URL pointing to a calendar collection that works as the default calendar. When there's noDAV:href, that means there's no default calendar. And if the property isn't there at all, there's no default calendar either. When there isn't one, the server gets to pick whichever calendar a new scheduling object resource goes into. See Section 4.3. 🫶
Definition:
<!ELEMENT schedule-default-calendar-URL (DAV:href?)>Example:
<C:schedule-default-calendar-URL xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:href>/home/cyrus/calendars/work/</D:href>
</C:schedule-default-calendar-URL>9.3. CALDAV:schedule-tag Property 🏷️
- Name:
schedule-tag - Namespace:
urn:ietf:params:xml:ns:caldav - Purpose: This tells you whether a scheduling object resource has gone through a "consequential" change. 👀
- Value:
opaque-tag(defined in Section 3.11 of [RFC2616]) - Protected: This property MUST be protected, since only the server gets to update the value. 🔐
- COPY/MOVE behavior: The server decides this value, and it MAY be different from the value on the source resource. 🌸
- Description: The CALDAV:schedule-tag property MUST be defined on all scheduling object resources, no exceptions bestie. 💅 This property is described in Section 3.2.10.
Definition:
<!ELEMENT schedule-tag (#PCDATA)>Example:
<C:schedule-tag xmlns:C="urn:ietf:params:xml:ns:caldav"
>"12345-67890"</C:schedule-tag>10. XML Element Definitions 🧁
10.1. CALDAV:schedule-response XML Element 🎀
- Name:
schedule-response - Namespace:
urn:ietf:params:xml:ns:caldav - Purpose: It holds the whole set of responses for a POST method request. 📦
- Description: See Section 5.
Definition:
<!ELEMENT schedule-response (response*)>10.2. CALDAV:response XML Element 💌
- Name:
response - Namespace:
urn:ietf:params:xml:ns:caldav - Purpose: One single response for a POST method request, served up fresh. 🍓
- Description: See Section 5.
Definition:
<!ELEMENT response (recipient,
request-status,
calendar-data?,
DAV:error?,
DAV:responsedescription?)>
<!-- CALDAV:calendar-data is defined in Section 9.6 of
RFC 4791 and when used here uses the definition with
content (#PCDATA) only. -->10.3. CALDAV:recipient XML Element 🫧
- Name:
recipient - Namespace:
urn:ietf:params:xml:ns:caldav - Purpose: This is the calendar user address that the enclosing response for a POST method request is meant for. 📬
- Description: See Section 5.
Definition:
<!ELEMENT recipient (DAV:href)>10.4. CALDAV:request-status XML Element 📋
- Name:
request-status - Namespace:
urn:ietf:params:xml:ns:caldav - Purpose: The iTIP "REQUEST-STATUS" property value for this response. It's the status tea. ☕
- Description: See Section 5.
Definition:
<!ELEMENT request-status (#PCDATA)>11. Security Considerations 🔐💀
This part is SERIOUS, bestie, so read it twice. 😭 Scheduling means sending and receiving scheduling messages, which means every general messaging security problem applies here too. The big one is making sure the authenticity of those scheduling messages is actually verified. Servers and clients MUST use an HTTP connection protected with Transport Layer Security (TLS) as defined in [RFC2818] for all scheduling operations. Clients MUST use the procedures detailed in Section 6 of [RFC6125] to verify the authenticity of the server. Servers MUST make use of HTTP authentication [RFC2617] to verify the authenticity of the calendar user for whom the client is sending requests. No shortcuts, periodt. 🙅♀️
11.1. Preventing Denial-of-Service Attacks 🚨
Servers MUST make sure clients can't eat up excessive server resources by running "large" scheduling operations. Ngl this is the bouncer job. 🧑💼 In particular, servers SHOULD enforce the CALDAV:max-resource-size, CALDAV:max-instances, and CALDAV:max-attendees-per-instance preconditions wherever they apply to scheduling Inbox and Outbox collections.
11.2. Verifying Scheduling Operations 🔍
When handling a scheduling operation, here's the checklist:
- Servers MUST verify that the principal associated with the DAV:owner of the calendar collection in which a scheduling object resource is being manipulated contains a CALDAV:schedule-outbox-URL property value.
- Servers MUST verify that the currently authenticated user has the CALDAV:schedule-send privilege, or a sub-privilege aggregated under this privilege, on the scheduling Outbox collection of the DAV:owner of the calendar collection in which a scheduling object resource is being manipulated.
- Servers MUST only deliver scheduling messages to recipients when the CALDAV:schedule-deliver privilege, or a sub-privilege aggregated under this privilege, is granted on the recipient's scheduling Inbox collection for the principal associated with the DAV:owner of the calendar collection in which a scheduling object resource is being manipulated.
- To prevent impersonation of calendar users, the server MUST verify that the "ORGANIZER" property in an organizer scheduling object resource matches one of the calendar user addresses of the DAV:owner of the calendar collection in which the resource is stored. 🎭
- To prevent spoofing of an existing scheduling object resource, servers MUST verify that the "UID" iCalendar property value in a new scheduling object resource does not match that of an existing scheduling object resource with a different "ORGANIZER" property value. 👻
11.3. Verifying Busy Time Information Requests 🕒
When handling a POST request on a scheduling Outbox collection:
- Servers MUST verify that the principal associated with the calendar user address specified in the "ORGANIZER" property of the scheduling message data in the request contains a CALDAV:schedule-outbox-URL property value that matches the scheduling Outbox collection targeted by the request.
- Servers MUST verify that the currently authenticated user has the CALDAV:schedule-send privilege, or a sub-privilege aggregated under this privilege, on the scheduling Outbox collection targeted by the request.
- Servers MUST only return valid freebusy information for recipients when the CALDAV:schedule-deliver privilege, or a sub-privilege aggregated under this privilege, is granted on the recipient's scheduling Inbox collection for the principal associated with the DAV:owner of the scheduling Outbox collection targeted by the request. 🙈
11.4. Privacy Issues 🫣
This spec only covers how calendar users on the same server can schedule with each other. Unauthenticated users have no way to carry out scheduling operations at all, so that's one less thing to worry about. 🙌 Access control privileges (as per Section 6) can control which of those users can schedule with others. Calendar users who don't want their calendar info exposed can deny privileges to specific users, or all users, for all scheduling operations, or maybe just freebusy. Lowkey the power is in your hands. 👑
"Attendees" can also use the Schedule-Reply request header (Section 8.1) with the value set to "F" to stop an "Organizer" from being notified that a scheduling object resource was deleted. This lets "Attendees" clear out unwanted scheduling messages without sending any response back to the "Organizer". 🧹
Servers MUST NOT expose any private iCalendar data, or WebDAV resource state information (URLs, WebDAV properties, etc.), from one calendar user to another via scheduling messages or error responses to scheduling operations. Iykyk, this is the no-gossip rule. 🤐 In particular, as per Section 8.1 of [RFC4918], authorization errors MUST take preference over other errors.
11.5. Mitigation of iTIP Threats 🛡️
Section 6.1 of iTIP [RFC5546] lays out a set of potential threats in a scheduling system, and Section 6.2 of [RFC5546] has recommendations on how to address them in protocols that use iTIP. Here's how this spec handles the iTIP threats:
- Spoofing the "Organizer": Addressed by item 4 in Section 11.2. 🎭
- Spoofing the "Attendee": Addressed by Section 3.2.2.1 and item 2 in Section 11.2. 🎭
- Unauthorized Replacement of the "Organizer": Addressed by item 5 in Section 11.2. 👻
- Eavesdropping and Data Integrity: Addressed by requiring TLS. 🔒
- Flooding a Calendar: Addressed by requirements in Section 11.1. 🌊
- Unauthorized REFRESH Requests: This specification does not support the REFRESH method. 🙅♀️
12. IANA Considerations 📚
12.1. Message Header Field Registrations 🎟️
The message header fields below have been added to the Permanent Message Header Field Registry (see [RFC3864]).
12.1.1. Schedule-Reply
- Header field name: Schedule-Reply
- Applicable protocol: http
- Status: standard
- Author/Change controller: IETF
- Specification document(s): this specification (Section 8.1)
- Related information: none
12.1.2. Schedule-Tag
- Header field name: Schedule-Tag
- Applicable protocol: http
- Status: standard
- Author/Change controller: IETF
- Specification document(s): this specification (Section 8.2)
- Related information: none
12.1.3. If-Schedule-Tag-Match
- Header field name: If-Schedule-Tag-Match
- Applicable protocol: http
- Status: standard
- Author/Change controller: IETF
- Specification document(s): this specification (Section 8.3)
- Related information: none
12.2. iCalendar Property Parameter Registrations 🗂️
The following iCalendar property parameter names have been added to the iCalendar Parameters Registry defined in Section 8.3.3 of [RFC5545].
+---------------------+---------+-----------------------+
| Parameter | Status | Reference |
+---------------------+---------+-----------------------+
| SCHEDULE-AGENT | Current | RFC 6638, Section 7.1 |
| | | |
| SCHEDULE-STATUS | Current | RFC 6638, Section 7.3 |
| | | |
| SCHEDULE-FORCE-SEND | Current | RFC 6638, Section 7.2 |
+---------------------+---------+-----------------------+12.3. iCalendar REQUEST-STATUS Value Registrations
okay bestie, these three iCalendar "REQUEST-STATUS" values just got added to the iCalendar REQUEST-STATUS Value Registry, which is defined in Section 7.3 of [RFC5546]. 🗂️✨ Here's the lineup:
+-------------+---------+---------------------------+
| Status Code | Status | Reference |
+-------------+---------+---------------------------+
| 1.0 | Current | RFC 6638, Section 3.2.9.1 |
| | | |
| 1.1 | Current | RFC 6638, Section 3.2.9.2 |
| | | |
| 1.2 | Current | RFC 6638, Section 3.2.9.3 |
+-------------+---------+---------------------------+12.4. Additional iCalendar Elements Registries
so per this spec, we got two brand new IANA registries for iCalendar elements 🎀 Extra codes MAY be used, but only if you register them through the process in Section 8.2.1 of [RFC5545]. No winging it, periodt 💅
12.4.1. Schedule Agent Values Registry
this table is what got used to kick off the Schedule Agent Values Registry 🤖
+----------------+---------+-----------------------+
| Schedule Agent | Status | Reference |
+----------------+---------+-----------------------+
| SERVER | Current | RFC 6638, Section 7.1 |
| | | |
| CLIENT | Current | RFC 6638, Section 7.1 |
| | | |
| NONE | Current | RFC 6638, Section 7.1 |
+----------------+---------+-----------------------+12.4.2. Schedule Force Send Values Registry
and this one is the starting set for the Schedule Force Send Values Registry 📮 Two values, both current, both pointing at Section 7.2.
+---------------------+---------+-----------------------+
| Schedule Force Send | Status | Reference |
+---------------------+---------+-----------------------+
| REQUEST | Current | RFC 6638, Section 7.2 |
| | | |
| REPLY | Current | RFC 6638, Section 7.2 |
+---------------------+---------+-----------------------+13. Acknowledgements 🫶
the authors really wanted to shout out these legends for sharing their ideas and backing this spec: Mike Douglass, Lisa Dusseault, Red Dutta, Jacob Farkas, Jeffrey Harris, Helge Hess, Eliot Lear, Andrew McMillan, Alexey Melnikov, Arnaud Quillaud, Julian F. Reschke, Wilfredo Sanchez Vega, and Simon Vaillancourt 🌸
they also thanked the Calendaring and Scheduling Consortium 🌈 for advice, and for running interoperability testing events that helped polish it up ✨
14. References 📚
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, May 2004.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, March 2007.
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009.
[RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent Interoperability Protocol (iTIP)", RFC 5546, December 2009.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, http://www.w3.org/TR/2008/REC-xml-20081126.
14.2. Informative References
[RFC6047] Melnikov, A., Ed., "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 6047, December 2010.
Appendix A. Scheduling Privileges Summary 🔑
A.1. Scheduling Inbox Privileges
this is the cheat sheet for which scheduling privileges let a calendar user drop a scheduling message into another calendar user's scheduling Inbox collection 📥 The right behavior depends on the calendar component type and the scheduling "METHOD" in the message, so read both columns, bestie 👀
+--------------------------------+
| METHOD for VEVENT and VTODO |
+-----------------------------+---------+-------+-----+--------+
| Scheduling Inbox Privilege | REQUEST | REPLY | ADD | CANCEL |
+-----------------------------+---------+-------+-----+--------+
| schedule-deliver | * | * | * | * |
| schedule-deliver-invite | * | | * | * |
| schedule-deliver-reply | | * | | |
| schedule-query-freebusy | | | | |
+-----------------------------+---------+-------+-----+--------+
+----------------------+
| METHOD for VFREEBUSY |
+-----------------------------+----------------------+
| Scheduling Inbox Privilege | REQUEST |
+-----------------------------+----------------------+
| schedule-deliver | * |
| schedule-deliver-invite | |
| schedule-deliver-reply | |
| schedule-query-freebusy | * |
+-----------------------------+----------------------+A.2. Scheduling Outbox Privileges
now the outbox side 📤 These privileges cover busy time information requests and submitting scheduling messages to other calendar users as the result of a scheduling operation. Same deal: the behavior depends on the component type and the "METHOD" 💅
+--------------------------------+
| METHOD for VEVENT and VTODO |
+-----------------------------+---------+-------+-----+--------+
| Scheduling Outbox Privilege | REQUEST | REPLY | ADD | CANCEL |
+-----------------------------+---------+-------+-----+--------+
| schedule-send | * | * | * | * |
| schedule-send-invite | * | | * | * |
| schedule-send-reply | | * | | |
| schedule-send-freebusy | | | | |
+-----------------------------+---------+-------+-----+--------+
+----------------------+
| METHOD for VFREEBUSY |
+-----------------------------+----------------------+
| Scheduling Outbox Privilege | REQUEST |
+-----------------------------+----------------------+
| schedule-send | * |
| schedule-send-invite | |
| schedule-send-reply | |
| schedule-send-freebusy | * |
+-----------------------------+----------------------+Appendix B. Example Scheduling Operations 🧚
this appendix walks through some example scheduling operations so you can get the general vibe of how CalDAV clients and servers handle scheduling, from the point of view of meeting "Organizers" and "Attendees" 🦋
the server is assumed to be hosted in the example.com domain, and users with email addresses at example.com are assumed to be hosted by the server. Addresses in the example.net domain are also valid for calendar users hosted by the server. Calendar users with an email address at the example.org domain are assumed to not be hosted by the server 🌍
heads up: in the examples that follow, the requests and responses are incomplete and only there for illustration. HTTP authentication headers and behaviors are left out, even though they are required in normal operation 🙈
B.1. Example: "Organizer" Inviting Multiple "Attendees" 🎀
Okay so in this one, Cyrus invites Wilfredo, Bernard, and Mike to a single instance event, and he does it super simply: he just creates a brand new scheduling object resource in one of his calendar collections using the PUT method. No cap, that's the whole thing 💅
>> Request <<
PUT /home/cyrus/calendars/work/9263504FD3AD.ics HTTP/1.1
Host: cal.example.com
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
If-None-Match: *
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VEVENT
UID:9263504FD3AD
SEQUENCE:0
DTSTAMP:20090602T185254Z
DTSTART:20090602T160000Z
DTEND:20090602T170000Z
TRANSP:OPAQUE
SUMMARY:Lunch
ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
mailto:cyrus@example.com
ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT
=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@
example.com
ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex
ample.net
ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A
CTION;RSVP=TRUE:mailto:mike@example.org
END:VEVENT
END:VCALENDAR>> Response <<
HTTP/1.1 201 Created
Content-Length: 0
Date: Tue, 02 Jun 2009 18:52:54 GMT
Last-Modified: Tue, 02 Jun 2009 18:52:54 GMT
ETag: "d85561cfe74a4e785eb4639451b434fb"
Schedule-Tag: "488177c8-2ea7-4176-a6cb-fab8cfccdea2"Once the event is created, Cyrus's client goes back to the server to fetch it, so it can see the schedule status of each "Attendee" and save the Schedule-Tag value for later. ✨ In this example, the server reports that a scheduling message was delivered to Wilfredo, a scheduling message is still pending for Bernard, and the server was unable to deliver a scheduling message to Mike. Ugh, poor Mike 🙈
>> Request <<
GET /home/cyrus/calendars/work/9263504FD3AD.ics HTTP/1.1
Host: cal.example.com>> Response <<
HTTP/1.1 200 OK
Date: Tue, 02 Jun 2009 18:52:58 GMT
Last-Modified: Tue, 02 Jun 2009 18:52:58 GMT
ETag: "eb897deabc8939589da116714bc99265"
Schedule-Tag: "488177c8-2ea7-4176-a6cb-fab8cfccdea2"
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN
BEGIN:VEVENT
UID:9263504FD3AD
SEQUENCE:0
DTSTAMP:20090602T185300Z
DTSTART:20090602T160000Z
DTEND:20090602T170000Z
TRANSP:OPAQUE
SUMMARY:Lunch
ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
mailto:cyrus@example.com
ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT
=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS=
1.2:mailto:wilfredo@e
xample.com
ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS=
1.0:mailto:bernard@example.net
ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A
CTION;RSVP=TRUE;SCHEDULE-STATUS=3.7:mailto:mike@example.org
END:VEVENT
END:VCALENDARB.2. Example: "Attendee" Receiving an Invitation 🦋
Next up, Wilfredo's client grabs the brand new scheduling message that landed in his scheduling Inbox collection. The server had already processed it automatically and made a new scheduling object resource in his default calendar collection. Once it's read, the client deletes the message from the Inbox, and that's a wrap 🌸
>> Request <<
GET /home/wilfredo/calendars/inbox/27d93fc0a58c.ics HTTP/1.1
Host: cal.example.com>> Response <<
HTTP/1.1 200 OK
Date: Tue, 02 Jun 2009 18:59:58 GMT
Last-Modified: Tue, 02 Jun 2009 18:59:58 GMT
ETag: "da116714bc9926c89395895eb897deab"
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN
METHOD:REQUEST
BEGIN:VEVENT
UID:9263504FD3AD
SEQUENCE:0
DTSTAMP:20090602T185254Z
DTSTART:20090602T160000Z
DTEND:20090602T170000Z
TRANSP:OPAQUE
SUMMARY:Lunch
ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
mailto:cyrus@example.com
ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT
=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@
example.com
ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex
ample.net
ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A
CTION;RSVP=TRUE:mailto:mike@example.org
END:VEVENT
END:VCALENDAR>> Request <<
DELETE /home/wilfredo/calendars/inbox/27d93fc0a58c.ics HTTP/1.1
Host: cal.example.com>> Response <<
HTTP/1.1 204 No Content
Date: Tue, 02 Jun 2009 20:40:36 GMTB.3. Example: "Attendee" Replying to an Invitation 💜
Now Wilfredo says yes to Cyrus's invite and adds an alarm reminder to the event. He's also being careful here: he uses the If-Schedule-Tag- Match precondition behavior so he won't accidentally overwrite any big changes the "Organizer" made after he first grabbed the resource data. That's what I call looking out for your bestie 🫶
>> Request <<
PUT /home/wilfredo/calendars/work/BB64861C2228.ics HTTP/1.1
Host: cal.example.com
If-Schedule-Tag-Match: "e78f23ed-0188-4bab-938d-2aeb3324c7e8"
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VEVENT
UID:9263504FD3AD
SEQUENCE:0
DTSTAMP:20090602T185254Z
DTSTART:20090602T160000Z
DTEND:20090602T170000Z
TRANSP:OPAQUE
SUMMARY:Lunch
ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
mailto:cyrus@example.com
ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT
=ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@exam
ple.com
ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex
ample.net
ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A
CTION;RSVP=TRUE:mailto:mike@example.org
BEGIN:VALARM
TRIGGER:-PT15M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR>> Response <<
HTTP/1.1 200 OK
Content-Length: 0
Date: Tue, 02 Jun 2009 18:57:54 GMT
Last-Modified: Tue, 02 Jun 2009 18:57:54 GMT
ETag: "eb4639451b434fbd85561cfe74a4e785"
Schedule-Tag: "8893ee45-eb9d-428f-b53c-c777daf19e41"Once the change is saved, Wilfredo's client fetches the event back from the server to see the schedule status of the "Organizer".
>> Request <<
GET /home/wilfredo/calendars/work/BB64861C2228.ics HTTP/1.1
Host: cal.example.com>> Response <<
HTTP/1.1 200 OK
Date: Tue, 02 Jun 2009 19:03:03 GMT
Last-Modified: Tue, 02 Jun 2009 19:02:21 GMT
ETag: "5eb897deabda116714bc9926c8939589"
Schedule-Tag: "8893ee45-eb9d-428f-b53c-c777daf19e41"
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VEVENT
UID:9263504FD3AD
SEQUENCE:0
DTSTAMP:20090602T190221Z
DTSTART:20090602T160000Z
DTEND:20090602T170000Z
TRANSP:OPAQUE
SUMMARY:Lunch
ORGANIZER;CN="Cyrus Daboo";SCHEDULE-STATUS=1.2:mailto:cyrus@ex
ample.com
ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
mailto:cyrus@example.com
ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT
=ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@exam
ple.com
ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex
ample.net
ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A
CTION;RSVP=TRUE:mailto:mike@example.org
BEGIN:VALARM
TRIGGER:-PT15M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDARB.4. Example: "Organizer" Receiving a Reply to an Invitation 🍓
Here's the glow-up moment. When Cyrus's server gets Wilfredo's reply, it does a few things on its own: it updates Cyrus's scheduling object resource, drops Wilfredo's scheduling message into Cyrus's scheduling Inbox collection, and sends an updated scheduling message to Bernard so he can see Wilfredo's new participation status. In this example, Cyrus's client grabs that message from his Inbox and deletes it. ✨
>> Request <<
GET /home/cyrus/calendars/inbox/c0a58c27d93f.ics HTTP/1.1
Host: cal.example.com>> Response <<
HTTP/1.1 200 OK
Date: Tue, 02 Jun 2009 19:05:02 GMT
Last-Modified: Tue, 02 Jun 2009 19:04:20 GMT
ETag: "9265eb897deabc8939589da116714bc9"
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN
METHOD:REPLY
BEGIN:VEVENT
UID:9263504FD3AD
SEQUENCE:0
DTSTAMP:20090602T185754Z
DTSTART:20090602T160000Z
DTEND:20090602T170000Z
ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
ATTENDEE;CN="Wilfredo Sanchez Vega";PARTSTAT=ACCEPTED:mailto:w
ilfredo@example.com
REQUEST-STATUS:2.0;Success
END:VEVENT
END:VCALENDAR>> Request <<
DELETE /home/cyrus/calendars/inbox/c0a58c27d93f.ics HTTP/1.1
Host: cal.example.com>> Response <<
HTTP/1.1 204 No Content
Date: Tue, 02 Jun 2009 19:05:05 GMTThen Cyrus's client pulls the event back from the server to check out Wilfredo's updated participation status. 🌈
>> Request <<
GET /home/cyrus/calendars/work/9263504FD3AD.ics HTTP/1.1
Host: cal.example.com>> Response <<
HTTP/1.1 200 OK
Date: Tue, 02 Jun 2009 19:05:02 GMT
Last-Modified: Tue, 02 Jun 2009 19:04:20 GMT
ETag: "eb897deabc8939589da116714bc99265"
Schedule-Tag: "132cab27-1fe3-67ab-de13-abd348d1dee3"
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN
BEGIN:VEVENT
UID:9263504FD3AD
SEQUENCE:0
DTSTAMP:20090602T190420Z
DTSTART:20090602T160000Z
DTEND:20090602T170000Z
TRANSP:OPAQUE
SUMMARY:Lunch
ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
mailto:cyrus@example.com
ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT
=ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS=2.0:
mailto:wilfredo@example.com
ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS=1
.0:mailto:bernard@example.net
ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A
CTION;RSVP=TRUE;SCHEDULE-STATUS=3.7:mailto:mike@example.org
END:VEVENT
END:VCALENDARB.5. Example: "Organizer" Requesting Busy Time Information
okay so in this one, Cyrus wants to peek at the busy time info for Wilfredo, Bernard, and Mike 👀✨
>> Request <<
POST /home/cyrus/calendars/outbox/ HTTP/1.1
Host: cal.example.com
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
METHOD:REQUEST
BEGIN:VFREEBUSY
UID:4FD3AD926350
DTSTAMP:20090602T190420Z
DTSTART:20090602T000000Z
DTEND:20090604T000000Z
ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
ATTENDEE;CN="Wilfredo Sanchez Vega":mailto:wilfredo@example.com
ATTENDEE;CN="Bernard Desruisseaux":mailto:bernard@example.net
ATTENDEE;CN="Mike Douglass":mailto:mike@example.org
END:VFREEBUSY
END:VCALENDAR>> Response <<
HTTP/1.1 200 OK
Date: Tue, 02 Jun 2009 20:07:34 GMT
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<C:schedule-response xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<C:response>
<C:recipient>
<D:href>mailto:wilfredo@example.com</D:href>
</C:recipient>
<C:request-status>2.0;Success</C:request-status>
<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN
METHOD:REPLY
BEGIN:VFREEBUSY
UID:4FD3AD926350
DTSTAMP:20090602T200733Z
DTSTART:20090602T000000Z
DTEND:20090604T000000Z
ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
ATTENDEE;CN="Wilfredo Sanchez Vega":mailto:wilfredo@example.com
FREEBUSY;FBTYPE=BUSY:20090602T110000Z/20090602T120000Z
FREEBUSY;FBTYPE=BUSY:20090603T170000Z/20090603T180000Z
END:VFREEBUSY
END:VCALENDAR
</C:calendar-data>
</C:response>
<C:response>
<C:recipient>
<D:href>mailto:bernard@example.net</D:href>
</C:recipient>
<C:request-status>2.0;Success</C:request-status>
<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN
METHOD:REPLY
BEGIN:VFREEBUSY
UID:4FD3AD926350
DTSTAMP:20090602T200733Z
DTSTART:20090602T000000Z
DTEND:20090604T000000Z
ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
ATTENDEE;CN="Bernard Desruisseaux":mailto:bernard@example.net
FREEBUSY;FBTYPE=BUSY:20090602T150000Z/20090602T160000Z
FREEBUSY;FBTYPE=BUSY:20090603T090000Z/20090603T100000Z
FREEBUSY;FBTYPE=BUSY:20090603T180000Z/20090603T190000Z
END:VFREEBUSY
END:VCALENDAR
</C:calendar-data>
</C:response>
<C:response>
<C:recipient>
<D:href>mailto:mike@example.org</D:href>
</C:recipient>
<C:request-status>3.7;Invalid calendar user</C:request-status>
</C:response>
</C:schedule-response>B.6. Example: User Attempting to Invite "Attendee" on Behalf of "Organizer"
so here Cyrus tries to make an event for Wilfredo and sneak Bernard in as an "Attendee" 🙅♀️ it fails, because Wilfredo never gave Cyrus the right to invite other calendar users on his behalf. not cute 💀
>> Request <<
PUT /home/wilfredo/calendars/work/def456.ics HTTP/1.1
Host: cal.example.com
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
If-None-Match: *
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VEVENT
UID:3504F926D3AD
SEQUENCE:0
DTSTAMP:20090602T190221Z
DTSTART:20090602T230000Z
DTEND:20090603T000000Z
TRANSP:OPAQUE
SUMMARY:Dinner
ORGANIZER;CN="Wilfredo Sanchez Vega":mailto:wilfredo@example.com
ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT=A
CCEPTED:mailto:wilfredo@example.com
ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=NE
EDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl
e.net
END:VEVENT
END:VCALENDAR>> Response <<
HTTP/1.1 403 Forbidden
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:need-privileges>
<D:resource>
<D:href>/home/wilfredo/calendars/outbox/</D:href>
<D:privilege><C:schedule-send-invite/></D:privilege>
</D:resource>
</D:need-privileges>
</D:error>B.7. Example: "Attendee" Declining an Instance of a Recurring Event
now Bernard is declining the second recurrence instance of a daily recurring event that Cyrus invited him to 🙅♂️💅
>> Request <<
PUT /home/bernard/calendars/work/4FD3AD926350.ics HTTP/1.1
Host: cal.example.com
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
If-Schedule-Tag-Match: "7775FB30-7534-489E-A79A-0EA147B933EB"
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VTIMEZONE
TZID:America/Montreal
BEGIN:STANDARD
DTSTART:20071104T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20070311T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:9263504FD3AD
SEQUENCE:0
DTSTAMP:20090602T185254Z
DTSTART;TZID=America/Montreal:20090601T150000
DTEND;TZID=America/Montreal:20090601T160000
RRULE:FREQ=DAILY;INTERVAL=1;COUNT=5
TRANSP:OPAQUE
SUMMARY:Review Internet-Draft
ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
mailto:cyrus@example.com
ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl
e.net
END:VEVENT
BEGIN:VEVENT
UID:9263504FD3AD
SEQUENCE:0
DTSTAMP:20090603T183823Z
RECURRENCE-ID;TZID=America/Montreal:20090602T150000
DTSTART;TZID=America/Montreal:20090602T150000
DTEND;TZID=America/Montreal:20090602T160000
TRANSP:TRANSPARENT
SUMMARY:Review Internet-Draft
ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
mailto:cyrus@example.com
ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
DECLINED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl
e.net
END:VEVENT
END:VCALENDAR>> Response <<
HTTP/1.1 200 OK
Content-Length: 0
Date: Tue, 02 Jun 2009 18:52:54 GMT
Last-Modified: Tue, 02 Jun 2009 18:52:54 GMT
ETag: "d85561cfe74a4e785eb4639451b434fb"
Schedule-Tag: "488177c8-2ea7-4176-a6cb-fab8cfccdea2"Bernard's participation status update will cause his server to deliver a scheduling message to Cyrus. Cyrus's client will find the following reply message from Bernard in Cyrus's scheduling Inbox collection:
>> Request <<
GET /home/cyrus/calendars/inbox/9263504FD3AD.ics HTTP/1.1
Host: cal.example.com>> Response <<
HTTP/1.1 200 OK
Date: Tue, 02 Jun 2009 18:52:58 GMT
Last-Modified: Tue, 02 Jun 2009 18:52:58 GMT
ETag: "eb897deabc8939589da116714bc99265"
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
METHOD:REPLY
BEGIN:VTIMEZONE
TZID:America/Montreal
BEGIN:STANDARD
DTSTART:20071104T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20070311T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:9263504FD3AD
SEQUENCE:0
DTSTAMP:20090603T183823Z
RECURRENCE-ID;TZID=America/Montreal:20090602T150000
DTSTART;TZID=America/Montreal:20090602T150000
DTEND;TZID=America/Montreal:20090602T160000
SUMMARY:Review Internet-Draft
ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
ATTENDEE;CN="Bernard Desruisseaux";PARTSTAT=DECLINED:
mailto:bernard@example.net
REQUEST-STATUS:2.0;Success
END:VEVENT
END:VCALENDARB.8. Example: "Attendee" Removing an Instance of a Recurring Event
this time Bernard goes a step further and removes the third recurrence instance of that same daily event from his calendar 🗑️ he does it by adding an "EXDATE" property to the scheduling object resource stored on his side. iykyk 🦋
>> Request <<
PUT /home/bernard/calendars/work/4FD3AD926350.ics HTTP/1.1
Host: cal.example.com
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
If-Schedule-Tag-Match: "488177c8-2ea7-4176-a6cb-fab8cfccdea2"
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VTIMEZONE
TZID:America/Montreal
BEGIN:STANDARD
DTSTART:20071104T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20070311T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:9263504FD3AD
SEQUENCE:0
DTSTAMP:20090602T185254Z
DTSTART;TZID=America/Montreal:20090601T150000
DTEND;TZID=America/Montreal:20090601T160000
RRULE:FREQ=DAILY;INTERVAL=1;COUNT=5
EXDATE;TZID=America/Montreal:20090603T150000
TRANSP:OPAQUE
SUMMARY:Review Internet-Draft
ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
mailto:cyrus@example.com
ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl
e.net
END:VEVENT
BEGIN:VEVENT
UID:9263504FD3AD
SEQUENCE:0
DTSTAMP:20090603T183823Z
RECURRENCE-ID;TZID=America/Montreal:20090602T150000
DTSTART;TZID=America/Montreal:20090602T150000
DTEND;TZID=America/Montreal:20090602T160000
TRANSP:TRANSPARENT
SUMMARY:Review Internet-Draft
ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
mailto:cyrus@example.com
ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
DECLINED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl
e.net
END:VEVENT
END:VCALENDAR>> Response <<
HTTP/1.1 200 OK
Content-Length: 0
Date: Tue, 02 Jun 2009 18:52:54 GMT
Last-Modified: Tue, 02 Jun 2009 18:52:54 GMT
ETag: "d85561cfe74a4e785eb4639451b434fb"
Schedule-Tag: "488177c8-2ea7-4176-a6cb-fab8cfccdea2"Bernard's deletion of a recurrence instance will cause his server to deliver a scheduling message to Cyrus. Cyrus's client will find the following reply message from Bernard in Cyrus's scheduling Inbox collection:
>> Request <<
GET /home/cyrus/calendars/inbox/6504923FD3AD.ics HTTP/1.1
Host: cal.example.com>> Response <<
HTTP/1.1 200 OK
Date: Tue, 02 Jun 2009 18:52:58 GMT
Last-Modified: Tue, 02 Jun 2009 18:52:58 GMT
ETag: "eb897deabc8939589da116714bc99265"
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
METHOD:REPLY
BEGIN:VTIMEZONE
TZID:America/Montreal
BEGIN:STANDARD
DTSTART:20071104T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20070311T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:9263504FD3AD
SEQUENCE:0
DTSTAMP:20090603T183823Z
RECURRENCE-ID;TZID=America/Montreal:20090603T150000
DTSTART;TZID=America/Montreal:20090603T150000
DTEND;TZID=America/Montreal:20090603T160000
SUMMARY:Review Internet-Draft
ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
ATTENDEE;CN="Bernard Desruisseaux";PARTSTAT=DECLINED:
mailto:bernard@example.net
REQUEST-STATUS:2.0;Success
END:VEVENT
END:VCALENDARAuthors' Addresses 💖
okay bestie, the authors!! 🫶 these are the two people who wrote this whole spec, and here's how to reach them if you need to 💅
Cyrus Daboo 🦋
Cyrus Daboo
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
EMail: cyrus@daboo.name
URI: http://www.apple.com/Bernard Desruisseaux 🧚
Bernard Desruisseaux
Oracle Corporation
600 Blvd. de Maisonneuve West
Suite 1900
Montreal, QC H3A 3J2
CANADA
EMail: bernard.desruisseaux@oracle.com
URI: http://www.oracle.com/That's the whole doc, babe 🎀 Thanks for reading all the way to the end ✨🌈
📦 where this page comes from
- ietf: rfc6638 2012-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms