RFC 8607

Calendaring Extensions to WebDAV (CalDAV): Managed Attachments

📅 published June 2019, from ietf

Calendaring Extensions to WebDAV (CalDAV): Managed Attachments 🎀

okay bestie, this is RFC 8607 💖 It's an Informational doc, not a Standards Track one, and it's dated June 2019. The authors are C. Daboo (Apple), A. Quillaud (Oracle), and K. Murchison, Ed. (FastMail). The ISSN is 2070-1721. The title block doesn't list anything this RFC obsoletes or updates, so there's no drama there 🫶

Abstract ✨

So this spec adds an extension to CalDAV so that attachments tied to iCalendar data can be stored and managed right on the server 🦋

It also says it's documenting code that multiple vendors already ship. It's published as Informational instead of Standards Track because it doesn't follow several HTTP best current practices 💅

Status of This Memo

This one is not an Internet Standards Track spec. It's published for info purposes 📚

It's a product of the IETF, it reflects IETF community consensus, got public review, and was approved for publication by the IESG. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you're curious 🤓

For current status, errata, or how to send feedback, go to https://www.rfc-editor.org/info/rfc8607 🌸

Copyright Notice

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. Read them carefully, because they spell out your rights and restrictions 🧐

Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as described in the Simplified BSD License 🫶

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Rationale for Informational Status  . . . . . . . . . . .   4
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   4
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Discovering Support for Managed Attachments . . . . . . .   5
     3.3.  POST Request for Managing Attachments . . . . . . . . . .   6
       3.3.1.  action Query Parameter  . . . . . . . . . . . . . . .   6
       3.3.2.  rid Query Parameter . . . . . . . . . . . . . . . . .   6
       3.3.3.  managed-id Query Parameter  . . . . . . . . . . . . .   7
     3.4.  Adding Attachments  . . . . . . . . . . . . . . . . . . .   7
     3.5.  Updating Attachments  . . . . . . . . . . . . . . . . . .  10
     3.6.  Removing Attachments via POST . . . . . . . . . . . . . .  13
     3.7.  Adding Existing Managed Attachments via PUT . . . . . . .  15
     3.8.  Updating Attachments via PUT  . . . . . . . . . . . . . .  15
     3.9.  Removing Attachments via PUT  . . . . . . . . . . . . . .  15
     3.10. Retrieving Attachments  . . . . . . . . . . . . . . . . .  15
     3.11. Error Handling  . . . . . . . . . . . . . . . . . . . . .  16
     3.12. Additional Considerations . . . . . . . . . . . . . . . .  17
       3.12.1.  Quotas . . . . . . . . . . . . . . . . . . . . . . .  17
       3.12.2.  Access Control . . . . . . . . . . . . . . . . . . .  17
       3.12.3.  Redirects  . . . . . . . . . . . . . . . . . . . . .  18
       3.12.4.  Processing Time  . . . . . . . . . . . . . . . . . .  18
       3.12.5.  Automatic Cleanup by Servers . . . . . . . . . . . .  18
       3.12.6.  Sending Scheduling Messages with Attachments . . . .  18
       3.12.7.  Migrating Calendar Data  . . . . . . . . . . . . . .  18
   4.  Modifications to iCalendar Syntax . . . . . . . . . . . . . .  19
     4.1.  SIZE Property Parameter . . . . . . . . . . . . . . . . .  19
     4.2.  FILENAME Property Parameter . . . . . . . . . . . . . . .  19
     4.3.  MANAGED-ID Property Parameter . . . . . . . . . . . . . .  20
   5.  Additional Message Header Fields  . . . . . . . . . . . . . .  20

     5.1.  Cal-Managed-ID Response Header Field  . . . . . . . . . .  20
   6.  Additional WebDAV Properties  . . . . . . . . . . . . . . . .  21
     6.1.  CALDAV:managed-attachments-server-URL Property  . . . . .  21
     6.2.  CALDAV:max-attachment-size Property . . . . . . . . . . .  22
     6.3.  CALDAV:max-attachments-per-resource Property  . . . . . .  23
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  24
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
     8.1.  Parameter Registrations . . . . . . . . . . . . . . . . .  24
     8.2.  Message Header Field Registrations  . . . . . . . . . . .  25
       8.2.1.  Cal-Managed-ID  . . . . . . . . . . . . . . . . . . .  25
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  25
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  27
   Appendix A.  Example Involving Recurring Events . . . . . . . . .  28
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  34
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  34

1. Introduction ✨

The iCalendar [RFC5545] format represents calendar data, and it's used together with iCalendar Transport-independent Interoperability Protocol (iTIP) [RFC5546] to handle scheduling between calendar users 📅

[RFC4791] defines the Calendaring Extensions to WebDAV (CalDAV), which sits on top of HTTP [RFC7230] and lets you access calendar data stored on a server 🌈

Calendar users super often want attachments on their events or tasks, like a copy of a presentation or the meeting agenda 💼 iCalendar has an ATTACH property, and its value is either inline Base64 encoded attachment data or a URL that points to where the attachment lives 🧚

Inline attachment data isn't ideal with CalDAV, bestie. The data would have to be uploaded to the server every single time the calendar data changes, even tiny stuff like editing the summary 😭 You could use a URL value instead, but then the questions become where the client finds a good URL and how to make sure only the people listed on the event or task can actually open it 🙈

So this spec fixes that. The client sends the attachment to the server separately from the iCalendar data, and the server adds the right ATTACH properties to the iCalendar data and handles the access privileges too 👑 The server can also tell the client extra stuff about each attachment in the iCalendar data, like its size and an identifier 💜

1.1. Rationale for Informational Status

Okay so this extension to CalDAV is widely deployed, but its design doesn't follow some HTTP best current practices, namely:

All operations on attachments are modeled as HTTP POST operations. The actual type of operation is specified with a query parameter, instead of using separate HTTP POST, PUT, and DELETE methods where those would fit 🙃
Specific query strings are hardwired into the protocol, which violates Section 2.4 of [RFC7320] 💀

This extension also misuses the Content-Disposition header field [RFC6266] as a request header field to carry a filename for an attachment 😬 It should have used an existing request header field made for that job, like Slug (see Section 9.7 of [RFC5023]).

Instead of breaking interop with code that's already deployed by updating the design to follow best current practices and pushing for Standards Track, the group decided to just document how the existing implementations interoperate and publish it as Informational 🫶 Pragmatic queen behavior ✨

2. Conventions Used in This Document 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💅 Lowercase versions are just regular words, so don't panic 🦋

The notation in this memo is the ABNF notation of [RFC5234], as used by iCalendar [RFC5545]. Any syntax elements shown below that aren't explicitly defined in this spec come from iCalendar [RFC5545] 📝

3. Overview 🌸

There are four main things a client needs to do with attachments for calendar data: add, update, remove, and retrieve 🧩 The first three happen when the client sends an HTTP POST request to the calendar object resource the attachment belongs to, with the right action query parameter (see Section 3.3) 💖 For removing, the client can also update the calendar object resource directly and take out the relevant ATTACH properties (see Section 3.9) ✨ Retrieving is simple: just send an HTTP GET to the attachment URI from the calendar resource's ATTACH property (see Section 3.10) 📥

iCalendar data in a CalDAV calendar object resource can hold multiple components when recurrences are involved 🔁 So the client needs a way to target one specific recurrence instance, or several, when adding or deleting attachments. That means the POST request has to say which recurrence instances the attachment operation should hit, and it does that with extra query parameters on the POST Request-URI 🎯

3.1. Requirements

A server that supports the features in this spec is REQUIRED to support the CalDAV calendar-access [RFC4791] features 🔐 No skipping this one, friends.

On top of that, such a server SHOULD support the return=representation Prefer header field [RFC7240] preference on successful HTTP PUT and POST requests that target existing calendar object resources 🌟 It does that by sending back the new representation of the calendar resource, including its new ETag header field value, in the response 💜

3.2. Discovering Support for Managed Attachments 🔍

A server that supports the features in this spec MUST include calendar-managed-attachments as a token in the DAV response header field (as defined in Section 10.1 of [RFC4918]) from an OPTIONS request on a calendar home collection 🧁

A server might choose not to store managed attachments per recurrence instance, meaning they can only be added to all instances as a whole, i.e., the whole series 🔁 If that's the case, the server MUST also include calendar-managed-attachments-no-recurrence as a token in the DAV response header field from an OPTIONS request on a calendar home collection 🙅‍♀️ When that field is there, clients MUST NOT attempt any managed attachment operations that target specific recurrence instances 🚫 Respect the boundaries, bestie 🫶

3.3. POST Request for Managing Attachments 💌

okay so this is the main event 💅 an HTTP POST request is how you add, update, or remove attachments. these requests are subject to the preconditions listed in Section 3.11, and the Request-URI carries query parameters that tell the server exactly what you're after 🎀

3.3.1. action Query Parameter 🎯

the "action" query parameter tells the server which attachment operation you're requesting ✨ it MUST be present once on each POST request used to manage attachments, and one of these three values MUST be used:

attachment-add: adds an attachment to a calendar object resource. see Section 3.4 for the deets 💖
attachment-update: updates an existing attachment on a calendar object resource. see Section 3.5 🦋
attachment-remove: removes an attachment from a calendar object resource. see Section 3.6 for more 🗑️

Example:

https://calendar.example.com/events/1.ics?action=attachment-add

3.3.2. rid Query Parameter 🌸

the "rid" query parameter says which recurrence instances the client is targeting 🧚 it MUST contain one or more items, separated by commas (denoted in ASCII as "0x2C"). each item can take one of two forms:

Master instance: the value "M" (case insensitive) refers to the "master" recurrence instance, i.e., the component that does not include a "RECURRENCE-ID" property. this item MUST be present only once 👑
Specific instance: a specific iCalendar instance is targeted by using its "RECURRENCE-ID" value as the item value. that value MUST correspond to the "RECURRENCE-ID" value as stored in the calendar object resource (i.e., without any conversion to UTC). if multiple items of this form are used, they MUST be unique values. for example, to target a recurrence defined by property RECURRENCE-ID;TZID=America/Montreal:20111022T160000, the query parameter rid=20111022T160000 would be used 🌈

if the "rid" query parameter is not present, all recurrence instances in the calendar object resource are targeted. 🫶

the "rid" query parameter MUST NOT be present in the case of an update operation, or if the server chooses not to support per-recurrence instance managed attachments (see Section 3.2). not me trying to sneak an update in with a rid 💀

Example (targeting the master instance and a specific overridden instance):

https://calendar.example.com/events/1.ics?
  action=attachment-add&rid=M,20111022T160000

3.3.3. managed-id Query Parameter 🆔

the "managed-id" query parameter identifies which "ATTACH" property is being updated or removed 🔍 its value MUST match the "MANAGED-ID" (Section 4.3) property parameter value on the "ATTACH" property in the calendar object resource instance(s) targeted by the request. this is the key that connects your request to the right attachment, so it has to match exactly 🔑

the "managed-id" query parameter MUST NOT be present in the case of an add operation. 🙅‍♀️

Example:

https://calendar.example.com/events/1.ics?
  action=attachment-update&managed-id=aUNhbGVuZGFy

3.4. Adding Attachments 📎

okay so to add an attachment to an existing calendar object resource, this is the whole flow 🎀

the client issues a POST request targeted at the calendar object resource, structured like this:
- A. the Request-URI will include an "action" query parameter with the value "attachment-add" (see Section 3.3.1).
- B. if all recurrence instances are having an attachment added, the "rid" query parameter is not present in the Request-URI. if one or more specific recurrence instances are targeted, then the Request-URI will include a "rid" query parameter containing the list of instances (see Section 3.3.2).
- C. the body of the request contains the data for the attachment.
- D. the client MUST include a valid Content-Type header field describing the media type of the attachment (as required by HTTP). no skipping this one bestie 🙅‍♀️
- E. the client SHOULD include a Content-Disposition header field [RFC6266] with a "type" parameter set to "attachment", and a "filename" parameter that indicates the name of the attachment. note that the use of Content-Disposition as a request header field is nonstandard and specific to this protocol 🤓
- F. the client MAY include a Prefer header field [RFC7240] with the "return=representation" preference to request that the modified calendar object resource be returned as the body of a successful response to the POST request. ✨
when the server receives the POST request, it does the following:
- A. validates that any recurrence instances referred to via the "rid" query parameter are valid for the calendar object resource being targeted 🔎
- B. stores the supplied attachment data into a resource and generates an appropriate URI for clients to access the resource 📦
- C. for each affected recurrence instance in the calendar object resource targeted by the request, adds an "ATTACH" property whose value is the URI of the stored attachment. the "ATTACH" property MUST contain a "MANAGED-ID" property parameter whose value is a unique identifier (within the context of the server as a whole). the "ATTACH" property SHOULD contain an "FMTTYPE" property parameter whose value matches the Content-Type header field value from the request. the "ATTACH" property SHOULD contain a "FILENAME" property parameter whose value matches the value of the Content-Disposition header field "filename" parameter value from the request, taking into account the restrictions expressed in Section 4.2. the "ATTACH" property SHOULD include a "SIZE" property parameter whose value represents the size in octets of the attachment. if a specified recurrence instance does not have a matching component in the calendar object resource, then the server MUST modify the calendar object resource to include an overridden component with the appropriate "RECURRENCE-ID" property. 🧩
- D. upon successful creation of the attachment resource, and modification of the targeted calendar object resource, it MUST return an appropriate HTTP success status response and include a "Cal-Managed-ID" header field containing the "MANAGED-ID" property parameter value of the newly created "ATTACH" property. the client can use the "Cal-Managed-ID" header field value to correlate the attachment with "ATTACH" properties added to the calendar object resource. if the client included a Prefer header field with the "return=representation" preference in the request, the server SHOULD return the modified calendar object resource as the body of the response. otherwise, the server can expect that the client will reload the calendar object resource with a subsequent GET request to refresh any local cache. 🔄

In the following example, the client adds a new attachment to a nonrecurring event and asks the server (via the Prefer header field [RFC7240]) to return the modified version of that event in the response. 💅

>> Request <<

POST /events/64.ics?action=attachment-add HTTP/1.1
Host: cal.example.com
Content-Type: text/html; charset="utf-8"
Content-Disposition:attachment;filename=agenda.html
Content-Length: 59
Prefer: return=representation

<html>
  <body>
    <h1>Agenda</h1>
  </body>
</html>

>> Response <<

HTTP/1.1 201 Created
Content-Type: text/calendar; charset="utf-8"
Content-Length: 371
Content-Location: https://cal.example.com/events/64.ics
ETag: "123456789-000-111"
Cal-Managed-ID: 97S

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN
BEGIN:VEVENT
UID:20010712T182145Z-123401@example.com
DTSTAMP:20120201T203412Z
DTSTART:20120714T170000Z
DTEND:20120715T040000Z
SUMMARY:One-off meeting
ATTACH;MANAGED-ID=97S;FMTTYPE=text/html;SIZE=59;
 FILENAME=agenda.html:https://cal.example.com/attach/64/34X22R
END:VEVENT
END:VCALENDAR

3.5. Updating Attachments ✨

okay so when an attachment gets updated, the server MUST change the MANAGED-ID property parameter, and it MAY change the ATTACH property value too 🦋. That's the trick. Other clients can tell something changed just by checking whether either the ATTACH value or the MANAGED-ID value is different now. Iconic design, honestly 💅.

To change the data of an existing managed attachment in a calendar object resource, here's the play:

The client sends a POST request aimed at the calendar object resource, and it's set up like this:
- A. The Request-URI includes an action query parameter with the value attachment-update (see Section 3.3.1) 🎀.
- B. The Request-URI includes a managed-id query parameter whose value matches the MANAGED-ID property parameter on the ATTACH property being updated (see Section 3.3.3) 🌸.
- C. The body of the request has the updated data for the attachment.
- D. The client MUST include a valid Content-Type header field that describes the media type of the attachment (as HTTP requires) 📄.
- E. The client SHOULD include a Content-Disposition header field [RFC6266] with a type parameter set to attachment, plus a filename parameter that names the attachment ✨.
- F. The client MAY include a Prefer header field [RFC7240] with the return=representation preference, asking for the modified calendar object resource to come back as the body of a successful response to the POST request 🧚.
When the server gets that POST request, it does the following:
- A. It validates that the managed-id query parameter is valid for the calendar object resource 🔍.
- B. It updates the content of the attachment resource that matches that managed-id value with the data it was given 💾.
- C. For each affected recurrence instance in the targeted calendar object resource, it updates the ATTACH property whose MANAGED-ID property parameter value matches the managed-id query parameter. The MANAGED-ID value gets changed so other clients can spot the update, and the property value (the attachment URI) might change too 🔄. The ATTACH property SHOULD contain a FMTTYPE property parameter whose value matches the Content-Type header field value from the request. That could be different from the original value if the media type of the updated attachment changed 🍓. The ATTACH property SHOULD contain a FILENAME property parameter whose value matches the filename parameter in the Content-Disposition header field from the request, taking into account the restrictions in Section 4.2 📛. The ATTACH property SHOULD include a SIZE property parameter whose value is the size in octets of the updated attachment 📏.
- D. Once the attachment resource is updated and the targeted calendar object resource is modified, the server MUST return an appropriate HTTP success status response and include a Cal-Managed-ID header field holding the new value of the MANAGED-ID property parameter. The client can use that Cal-Managed-ID value to match the attachment up with ATTACH properties added to the calendar object resource 🔗. If the client sent a Prefer header field with the return=representation preference, the server SHOULD return the modified calendar object resource as the body of the response. Otherwise, the server can expect the client to reload the calendar object resource with a later GET request to refresh any local cache 🔁.

The update operation does not take a rid query parameter, and it doesn't add or remove any ATTACH property in the targeted calendar object resource. So if you want to link an existing attachment to a new instance, you just do a PUT on the calendar object resource and add an ATTACH property that duplicates the existing one (see Section 3.7) 🫶.

Here's an example where the client updates an existing attachment and uses the Prefer header field [RFC7240] to ask the server for the updated event back in the response 💖.

>> Request <<

POST /events/64.ics?action=attachment-update&managed-id=97S HTTP/1.1
Host: cal.example.com
Content-Type: text/html; charset="utf-8"
Content-Disposition:attachment;filename=agenda.html
Content-Length: 96
Prefer: return=representation

<html>
  <body>
    <h1>Agenda</h1>
    <p>Discuss attachment draft</p>
  </body>
</html>

>> Response <<

HTTP/1.1 200 OK
Content-Type: text/calendar; charset="utf-8"
Content-Length: 371
Content-Location: https://cal.example.com/events/64.ics
Cal-Managed-ID: 98S
ETag: "123456789-000-222"

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN
BEGIN:VEVENT
UID:20010712T182145Z-123401@example.com
DTSTAMP:20120201T203412Z
DTSTART:20120714T170000Z
DTEND:20120715T040000Z
SUMMARY:One-off meeting
ATTACH;MANAGED-ID=98S;FMTTYPE=text/html;SIZE=96;
 FILENAME=agenda.html:https://cal.example.com/attach/64/34X22R
END:VEVENT
END:VCALENDAR

3.6. Removing Attachments via POST 🗑️

Want to remove an existing attachment from a calendar object? Here's how:

The client sends a POST request aimed at the calendar object resource, structured like this:
- A. The Request-URI includes an action query parameter with the value attachment-remove (see Section 3.3.1) 💀.
- B. If every recurrence instance is having an attachment removed, the rid query parameter is not present in the Request-URI. If one or more specific recurrence instances are targeted, then the Request-URI includes a rid query parameter listing those instances (see Section 3.3.2) 🎯.
- C. The Request-URI includes a managed-id query parameter whose value matches the MANAGED-ID property parameter on the ATTACH property being removed (see Section 3.3.3) 🔑.
- D. The body of the request is empty 🫧.
- E. The client MAY include a Prefer header field [RFC7240] with the return=representation preference, asking for the modified calendar object resource to come back as the body of a successful response to the POST request 🌈.
When the server gets the POST request, it does the following:
- A. It validates that any recurrence instances referred to via the rid query parameter are valid for the calendar object resource being targeted 🧐.
- B. It validates that the managed-id query parameter is valid for the calendar object resource and the specific instances being targeted ✅.
- C. For each affected recurrence instance in the targeted calendar object resource, it removes the matching ATTACH property. Here's the catch: if a specified recurrence instance doesn't have a matching component in the calendar object resource, then the server MUST modify the calendar object resource to include an overridden component with the appropriate RECURRENCE-ID property and the matching ATTACH property removed. This latter case is only valid if the master component does include the referenced ATTACH property 🙈.
- D. If no instance of the calendar object resource references the attachment resource anymore, it can delete the attachment resource to free up storage space 🧹.
- E. Once the attachment resource is removed and the targeted calendar object resource is modified, the server MUST return an appropriate HTTP success status response. If the client sent a Prefer header field with the return=representation preference, the server SHOULD return the modified calendar object resource as the body of the response. Otherwise, the server can expect the client to reload the calendar object resource with a later GET request to refresh any local cache 🔁.

In the following example, the client deletes an existing attachment by passing its managed-id value in the request. The Prefer header field [RFC7240] isn't set in the request, so the calendar object resource data doesn't come back in the response 🦋.

>> Request <<

POST /events/64.ics?action=attachment-remove&managed-id=98S HTTP/1.1
Host: cal.example.com
Content-Length: 0

>> Response <<

HTTP/1.1 204 No Content
Content-Length: 0

3.7. Adding Existing Managed Attachments via PUT 🧲

Clients can reuse existing managed attachments by adding the matching ATTACH property to calendar object resources. This is subject to the restrictions described in Section 3.12.2 💕.

If a managed attachment is used in more than one calendar resource, servers SHOULD NOT change either the MANAGED-ID property parameter value or the ATTACH property value for those attachments. This way, clients don't have to download the attachment data again if they already have it cached 💾. Also, servers SHOULD validate SIZE property parameter values and replace any incorrect values with the actual sizes of the existing attachments 📐.

These PUT requests are subject to the preconditions listed in Section 3.11 🌸.

3.8. Updating Attachments via PUT 🚫

Servers MUST NOT let clients update attachment data directly via a PUT on the attachment URI (or via any other HTTP method that modifies content). Instead, attachments can only be updated through POST requests on the calendar data 🙅‍♀️.

3.9. Removing Attachments via PUT 🫠

Clients can remove attachments by just rewriting the calendar object resource data to take out the appropriate ATTACH properties ✂️. Servers MUST NOT let clients delete attachments directly via a DELETE request on the attachment URI 🚷.

3.10. Retrieving Attachments 📥

Clients retrieve attachments by sending an HTTP GET request, using the value of the matching ATTACH property as the Request-URI. They have to take into account the substitution mechanism tied to the CALDAV:managed-attachments-server-URL property (see Section 6.1) 🧚‍♀️✨.

3.11. Error Handling 🚨

okay so this bit is about what happens when a request breaks the rules 🙅‍♀️ This spec adds some extra preconditions for the POST method, and they're basically the bouncers at the club deciding who gets in 🎀

The new preconditions are:

(CALDAV:max-attachment-size): The attachment submitted in the POST request MUST have an octet size less than or equal to the value of the "CALDAV:max-attachment-size" property value (Section 6.2) on the calendar collection of the target calendar resource. 📏
(CALDAV:max-attachments-per-resource): The addition of the attachment submitted in the POST request MUST result in the target calendar resource having a number of managed attachments less than or equal to the value of the "CALDAV:max-attachments-per-resource" property value (Section 6.3) on the calendar collection of the target calendar resource. 📎
(CALDAV:valid-action): The "action" query parameter in the POST request MUST contain only one of the following three values: "attachment-add", "attachment-update", or "attachment-remove". 🎯
(CALDAV:valid-rid): The "rid" query parameter in the POST request MUST NOT be present with an "action=attachment-update" query parameter and MUST contain the value "M" and/or values corresponding to "RECURRENCE-ID" property values in the iCalendar data targeted by the request. 🌸
(CALDAV:valid-managed-id): The "managed-id" query parameter in the POST request MUST NOT be present with an "action=attachment-add" query parameter and MUST contain a value corresponding to a "MANAGED-ID" property parameter value in the iCalendar data targeted by the request. 🦋

A POST request to add, modify, or delete a managed attachment results in an implicit modification of the targeted calendar resource (equivalent of a PUT). 🤯 As a consequence, clients should also be prepared to handle preconditions associated with this implicit PUT. This includes (but is not limited to):

(CALDAV:max-resource-size) (from Section 5.3.2.1 of [RFC4791])
(DAV:quota-not-exceeded) (from Section 6 of [RFC4331])
(DAV:sufficient-disk-space) (from Section 6 of [RFC4331])

A PUT request to add or modify an existing calendar object resource can make reference to an existing managed attachment. The following new precondition is defined:

(CALDAV:valid-managed-id-parameter): a "MANAGED-ID" property parameter value in the iCalendar data in the PUT request is not valid (e.g., does not match any existing managed attachment). 🙃

If a precondition for a request is not satisfied:

The response status of the request MUST either be 403 (Forbidden) if the request should not be repeated because it will always fail, or 409 (Conflict) if it is expected that the user might be able to resolve the conflict and resubmit the request. 🔁
The appropriate XML element MUST be returned as the child of a top-level DAV:error element in the response body. 🧾

3.12. Additional Considerations ✨

3.12.1. Quotas 💾

The WebDAV Quotas specification [RFC4331] defines two live WebDAV properties (DAV:quota-available-bytes and DAV:quota-used-bytes) to communicate storage quota information to clients. Server implementations MAY choose to include managed attachment sizes when calculating the amount of storage used by a particular resource. 🍓

3.12.2. Access Control 🔐

Access to the managed attachments referenced in a calendar object resource SHOULD be restricted to only those calendar users who have access to that calendar object either directly or indirectly (via being an attendee who would receive a scheduling message). 👀

When accessing a managed attachment, clients SHOULD be prepared to authenticate with the server storing the attachment resource. The credentials required to access the managed attachment store could be different from the ones used to access the CalDAV server. 🗝️

This specification only allows organizers of scheduled events to add managed attachments. Servers MUST prevent attendees of scheduled events from adding, updating, or removing managed attachments. In addition, the server MUST prevent a calendar user from reusing a managed attachment (based on its "managed-id" value), unless that user is the one who originally created the managed attachment. 👑 Organizers only, babe, no attendee drama allowed 🙅‍♀️

3.12.3. Redirects 🔀

For POST requests that add or update attachment data, the server MAY issue a 307 (Temporary Redirect) [RFC7231] or 308 (Permanent Redirect) [RFC7538] response to require the client to reissue the POST request using a different Request-URI. As a result, clients SHOULD use the "100-continue" expectation defined in Section 5.1.1 of [RFC7231]. Using this mechanism ensures that, if a redirect does occur, the client does not needlessly send the attachment data. 🙌

3.12.4. Processing Time ⏳

Clients can expect servers to take a while to respond to POST requests that include large attachment bodies. Servers SHOULD use the 102 (Processing) interim response defined in Section 10.1 of [RFC2518] to keep the client connection alive if the POST request will take significant time to complete. 💤

3.12.5. Automatic Cleanup by Servers 🧹

Servers MAY automatically remove attachment data, for example, to regain the storage taken by unused attachments or as the result of a virus scanning. When doing so, they SHOULD NOT modify calendar data referencing those attachments. Instead, they SHOULD respond with 410 (Gone) to any request on the removed attachment URI. 🪦

3.12.6. Sending Scheduling Messages with Attachments 📨

When a managed attachment is added, updated, or removed from a calendar object resource, the server MUST ensure that a scheduling message is sent to update any attendees with the changes, as per [RFC6638]. 💌 Everyone gets the tea, no one gets left out 🫖

3.12.7. Migrating Calendar Data 🧳

When exporting calendar data from a CalDAV server supporting managed attachments, clients SHOULD remove all "MANAGED-ID" property parameters from "ATTACH" properties in the calendar data. Similarly, when importing calendar data from another source, clients SHOULD remove any "MANAGED-ID" property parameters on "ATTACH" properties (failure to do so will likely result in the server removing those properties automatically). 🛫

4. Modifications to iCalendar Syntax 🎀

4.1. SIZE Property Parameter 📐

Parameter Name: SIZE

Purpose: To specify the size of an attachment.

Format Definition: This property parameter is defined by the following notation:

sizeparam = "SIZE" "=" paramtext
; positive integers

Description: This property parameter MAY be specified on "ATTACH" properties. It indicates the size in octets of the corresponding attachment data. Since iCalendar integer values are restricted to a maximum value of 2147483647, the current property parameter is defined as text to allow an extended range to be used. 🔢

Example:

ATTACH;SIZE=1234:https://attachments.example.com/abcd.txt

4.2. FILENAME Property Parameter 🗂️

Parameter Name: FILENAME

Purpose: To specify the filename of a managed attachment.

Format Definition: This property parameter is defined by the following notation:

filenameparam = "FILENAME" "=" paramtext

Description: This property parameter MAY be specified on "ATTACH" properties corresponding to managed attachments. Its value provides information on how to construct a filename for storing the attachment data. This parameter is very similar in nature to the Content-Disposition header field "filename" parameter and exposes the same security risks. As a consequence, clients MUST follow the guidelines expressed in Section 4.3 of [RFC6266] when consuming this property parameter value. Similarly, servers MUST follow those same guidelines before storing a value. ⚠️ Filenames are sus, bestie, so be careful with them 🫣

Example:

ATTACH;FILENAME=agenda.html:
 https://attachments.example.com/rt452S

4.3. MANAGED-ID Property Parameter 🆔

Parameter Name: MANAGED-ID

Purpose: To uniquely identify a managed attachment.

Format Definition: This property parameter is defined by the following notation:

managedidparam = "MANAGED-ID" "=" paramtext

Description: This property parameter MUST be specified on "ATTACH" properties corresponding to managed attachments. Its value is generated by the server and uniquely identifies a managed attachment within the scope of the CalDAV server. This property parameter MUST NOT be present in the case of unmanaged attachments. 🪪

Example:

ATTACH;MANAGED-ID=aUNhbGVuZGFy:
 https://attachments.example.com/abcd.txt

5. Additional Message Header Fields 💌

5.1. Cal-Managed-ID Response Header Field 🏷️

The Cal-Managed-ID response header field provides the value of the "MANAGED-ID" property parameter corresponding to a newly added "ATTACH" property.

ABNF:

Cal-Managed-ID = "Cal-Managed-ID" ":" paramtext
; "paramtext" is defined in Section 3.1 of [RFC5545]

Example:

Cal-Managed-ID:aUNhbGVuZGFy

The Cal-Managed-ID header field MUST only be sent by an origin server in response to a successful POST request with an "action" query parameter set to "attachment-add" or "attachment-update". It MUST only appear once in a response and MUST NOT appear in trailers. 📬

The Cal-Managed-ID header field is end to end and MUST be forwarded by intermediaries. Intermediaries MUST NOT insert, delete, or modify a Cal-Managed-ID header field. 🚚 hands off, middlemen 🙅‍♀️

6. Additional WebDAV Properties 🌈

6.1. CALDAV:managed-attachments-server-URL Property 🌐

Name: managed-attachments-server-URL

Namespace: urn:ietf:params:xml:ns:caldav

Purpose: This property specifies the server base URI to use when retrieving managed attachments.

Protected: This property MUST be protected as only the server can update the value. 🔒

COPY/MOVE behavior: This property is only defined on a calendar home collection, which cannot be moved or copied. 🚫📦

allprop behavior: This property SHOULD NOT be returned by a PROPFIND DAV:allprop request. 🙈

Description: This property MAY be defined on a calendar home collection. If present, it contains either a single DAV:href XML element or none at all.

When one DAV:href element is present, its value MUST be an absolute HTTP URI containing only the scheme (i.e., "https") and authority (i.e., host and port) parts. Whenever a managed attachment is to be retrieved via an HTTP GET, the client MUST construct the actual URL of the attachment by substituting the scheme and authority parts of the attachment URI (as stored in the iCalendar "ATTACH" property) with the present WebDAV property value.

When no DAV:href element is present, the client MUST substitute the scheme and authority parts of the attachment URI with the scheme and authority part of the calendar home collection absolute URI.

In the absence of this property, the client can consider the attachment URI as its actual URL. 🔗

Definition:

<!ELEMENT managed-attachments-server-URL (DAV:href?)>

Example:

<C:managed-attachments-server-URL xmlns:D="DAV:"
    xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:href>https://attachstore.example.com</D:href>
</C:managed-attachments-server-URL>

6.2. CALDAV:max-attachment-size Property ✨

Name: max-attachment-size 🎀
Namespace: urn:ietf:params:xml:ns:caldav 🌸
Purpose: okay so this one gives you a number for the biggest managed attachment the server is willing to accept when it stores one. The unit is octets 📏
Protected: this property MUST be protected, because it shows the limits the server set 🔒
COPY/MOVE behavior: this property value MUST be preserved in COPY and MOVE operations 🦋
allprop behavior: this property SHOULD NOT be returned by a PROPFIND DAV:allprop request 🙈

The CALDAV:max-attachment-size property tells you the maximum attachment size, in octets, that the server will accept when a managed attachment gets stored. It lives on the parent collection of the calendar object resource the attachment belongs to. If someone tries to store a managed attachment bigger than this, it MUST result in an error, and the CALDAV:max-attachment-size precondition (Section 3.11) gets violated. 💅 If the property isn't there at all, the client can just assume the server will take an attachment of any reasonable size 🫶

Definition:

<!ELEMENT max-attachment-size (#PCDATA)>
<!-- PCDATA value: a numeric value (positive decimal integer) -->

Example:

<C:max-attachment-size xmlns:C="urn:ietf:params:xml:ns:caldav"
     >102400000</C:max-attachment-size>

6.3. CALDAV:max-attachments-per-resource Property 🌈

Name: max-attachments-per-resource 🧚
Namespace: urn:ietf:params:xml:ns:caldav 💜
Purpose: this one gives a number for the maximum count of managed attachments across all instances of a calendar object resource that's stored in a calendar collection 📚
Protected: this property MUST be protected, because it shows the limits the server set 🔒
COPY/MOVE behavior: this property value MUST be preserved in COPY and MOVE operations 🦋
allprop behavior: this property SHOULD NOT be returned by a PROPFIND DAV:allprop request 🙈

The CALDAV:max-attachments-per-resource property is the cap on how many managed attachments can exist across all instances of a calendar object resource in a calendar collection. Unmanaged attachments don't count toward that cap, which is so iconic of them 🍓 The property lives on the parent collection of the calendar object resource the attachment is tied to. If adding a managed attachment would push the calendar resource over this limit, it MUST result in an error, and the CALDAV:max-attachments-per-resource precondition (Section 3.11) gets violated. 😭 Without this property, the client can assume the server can handle any number of managed attachments per calendar resource ✨

Definition:

<!ELEMENT max-attachments-per-resource (#PCDATA)>
<!-- PCDATA value: a numeric value (positive decimal integer) -->

Example:

<C:max-attachments-per-resource
    xmlns:C="urn:ietf:params:xml:ns:caldav"
     >12</C:max-attachments-per-resource>

7. Security Considerations 🚨

Okay, serious bestie moment 🥺 The security considerations in [RFC4791] and [RFC4918] apply to this extension. On top of that, servers need to be aware that a client could attack the underlying storage by POSTing extremely large attachments. A client could also attack processing time by uploading a recurring event with a large number of overrides and then repeatedly adding, updating, and deleting attachments. Yikes 💀

Malicious content could get into the calendar server through a managed attachment, and then spread to lots of end users through scheduling. Servers SHOULD check managed attachments for malicious or inappropriate content. If they detect that kind of content, servers SHOULD remove the attachment by following the rules in Section 3.12.5. Not on my watch 😤🔥

8. IANA Considerations 📋

8.1. Parameter Registrations 🗂️

This specification defines the following new iCalendar property parameters, which get added to the "Parameters" registry defined in Section 8.2.4 of [RFC5545]:

          +------------+---------+-----------------------+
          | Parameter  | Status  | Reference             |
          +------------+---------+-----------------------+
          | SIZE       | Current | RFC 8607, Section 4.1 |
          | FILENAME   | Current | RFC 8607, Section 4.2 |
          | MANAGED-ID | Current | RFC 8607, Section 4.3 |
          +------------+---------+-----------------------+

8.2. Message Header Field Registrations 📮

The message header fields below should be added to the "Permanent Message Header Field Names" registry (see [RFC3864]).

8.2.1. Cal-Managed-ID 💌

Header field name: Cal-Managed-ID
Protocol: http
Status: standard
Author/Change controller: IETF
Reference: this specification (Section 5.1)
Related information: none

9. References 📚

9.1. Normative References 💖

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC2518]  Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
           Jensen, "HTTP Extensions for Distributed Authoring --
           WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999,
           <https://www.rfc-editor.org/info/rfc2518>.

[RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
           Procedures for Message Header Fields", BCP 90, RFC 3864,
           DOI 10.17487/RFC3864, September 2004,
           <https://www.rfc-editor.org/info/rfc3864>.

[RFC4331]  Korver, B. and L. Dusseault, "Quota and Size Properties
           for Distributed Authoring and Versioning (DAV)
           Collections", RFC 4331, DOI 10.17487/RFC4331, February
           2006, <https://www.rfc-editor.org/info/rfc4331>.

[RFC4791]  Daboo, C., Desruisseaux, B., and L. Dusseault,
           "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
           DOI 10.17487/RFC4791, March 2007,
           <https://www.rfc-editor.org/info/rfc4791>.

[RFC4918]  Dusseault, L., Ed., "HTTP Extensions for Web Distributed
           Authoring and Versioning (WebDAV)", RFC 4918,
           DOI 10.17487/RFC4918, June 2007,
           <https://www.rfc-editor.org/info/rfc4918>.

[RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
           Specifications: ABNF", STD 68, RFC 5234,
           DOI 10.17487/RFC5234, January 2008,
           <https://www.rfc-editor.org/info/rfc5234>.

[RFC5545]  Desruisseaux, B., Ed., "Internet Calendaring and
           Scheduling Core Object Specification (iCalendar)",
           RFC 5545, DOI 10.17487/RFC5545, September 2009,
           <https://www.rfc-editor.org/info/rfc5545>.

[RFC6266]  Reschke, J., "Use of the Content-Disposition Header Field
           in the Hypertext Transfer Protocol (HTTP)", RFC 6266,
           DOI 10.17487/RFC6266, June 2011,
           <https://www.rfc-editor.org/info/rfc6266>.

[RFC6638]  Daboo, C. and B. Desruisseaux, "Scheduling Extensions to
           CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012,
           <https://www.rfc-editor.org/info/rfc6638>.

[RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
           Protocol (HTTP/1.1): Message Syntax and Routing",
           RFC 7230, DOI 10.17487/RFC7230, June 2014,
           <https://www.rfc-editor.org/info/rfc7230>.

[RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
           Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
           DOI 10.17487/RFC7231, June 2014,
           <https://www.rfc-editor.org/info/rfc7231>.

[RFC7240]  Snell, J., "Prefer Header for HTTP", RFC 7240,
           DOI 10.17487/RFC7240, June 2014,
           <https://www.rfc-editor.org/info/rfc7240>.

[RFC7538]  Reschke, J., "The Hypertext Transfer Protocol Status Code
           308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538,
           April 2015, <https://www.rfc-editor.org/info/rfc7538>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2. Informative References 🧠

[RFC5023]  Gregorio, J., Ed. and B. de hOra, Ed., "The Atom
           Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023,
           October 2007, <https://www.rfc-editor.org/info/rfc5023>.

[RFC5546]  Daboo, C., Ed., "iCalendar Transport-Independent
           Interoperability Protocol (iTIP)", RFC 5546,
           DOI 10.17487/RFC5546, December 2009,
           <https://www.rfc-editor.org/info/rfc5546>.

[RFC7320]  Nottingham, M., "URI Design and Ownership", BCP 190,
           RFC 7320, DOI 10.17487/RFC7320, July 2014,
           <https://www.rfc-editor.org/info/rfc7320>.

[RFC8144]  Murchison, K., "Use of the Prefer Header Field in Web
           Distributed Authoring and Versioning (WebDAV)", RFC 8144,
           DOI 10.17487/RFC8144, April 2017,
           <https://www.rfc-editor.org/info/rfc8144>.

Appendix A. Example Involving Recurring Events ✨

okay so this example is giving "recurring meeting drama" 💅 The organizer tries to add an HTML agenda to the meeting's calendar resource with a conditional request, and it does NOT work at first 💀 The client sends both the Expect and Prefer header fields, which means it won't waste time sending the attachment data if the precondition fails, and it asks the server to send back the current resource in the failure response (see Section 3.2 of [RFC8144]) 🧠

Request

   >> Request <<

   POST /events/65.ics?action=attachment-add HTTP/1.1
   Host: cal.example.com
   Content-Type: text/html; charset="utf-8"
   Content-Disposition: attachment;filename=agenda.html
   Content-Length: 80
   If-Match: "abcdefg-000"
   Expect: 100-continue
   Prefer: return=representation
   >> Final Response <<

   HTTP/1.1 412 Precondition Failed
   Content-Type: text/calendar; charset="utf-8"
   Content-Length: 929
   Content-Location: https://cal.example.com/events/65.ics
   ETag: "123456789-000-000"

   BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Server//EN
   BEGIN:VTIMEZONE
   LAST-MODIFIED:20040110T032845Z
   TZID:America/Montreal
   BEGIN:DAYLIGHT
   DTSTART:20000404T020000
   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
   TZNAME:EDT
   TZOFFSETFROM:-0500
   TZOFFSETTO:-0400
   END:DAYLIGHT
   BEGIN:STANDARD
   DTSTART:20001026T020000
   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
   TZNAME:EST
   TZOFFSETFROM:-0400
   TZOFFSETTO:-0500
   END:STANDARD
   END:VTIMEZONE
   BEGIN:VEVENT
   UID:20010712T182145Z-123401@example.com
   DTSTAMP:20120201T203412Z
   DTSTART;TZID=America/Montreal:20120206T100000
   DURATION:PT1H
   RRULE:FREQ=WEEKLY
   SUMMARY:Planning Meeting
   ORGANIZER:mailto:cyrus@example.com
   ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@exampl
    e.com
   ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:arnaudq@exam
    ple.com
   ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:mike@exa
    mple.com
   END:VEVENT
   END:VCALENDAR

The 412 is the server saying "nope, your precondition didn't match" 🙅‍♀️ but it still sends back the current calendar, so the client can see what's actually there ✨

The organizer tries again with the right If-Match value, and this time it totally works 🎉 The organizer successfully adds the agenda (HTML attachment) to the calendar resource. Attendees of the meeting get read access to the newly created attachment resource 🔓 Their own copy of the meeting gets updated with a new "ATTACH" property pointing at the attachment resource, and they get notified of the change through their scheduling inbox 📬

Request

   >> Request <<

   POST /events/65.ics?action=attachment-add HTTP/1.1
   Host: cal.example.com
   Content-Type: text/html; charset="utf-8"
   Content-Disposition: attachment;filename=agenda.html
   Content-Length: 80
   If-Match: "123456789-000-000"
   Expect: 100-continue
   Prefer: return=representation


   >> Interim Response <<

   HTTP/1.1 100 Continue


   >> Request Body <<

   <html>
     <body>
       <h1>Agenda</h1>
       <p>As usual</p>
     </body>
   </html>
   >> Final Response <<

   HTTP/1.1 201 Created
   Content-Type: text/calendar; charset="utf-8"
   Content-Length: 1043
   Content-Location: https://cal.example.com/events/65.ics
   ETag: "123456789-000-111"
   Cal-Managed-ID: 97S

   BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Server//EN
   BEGIN:VTIMEZONE
   LAST-MODIFIED:20040110T032845Z
   TZID:America/Montreal
   BEGIN:DAYLIGHT
   DTSTART:20000404T020000
   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
   TZNAME:EDT
   TZOFFSETFROM:-0500
   TZOFFSETTO:-0400
   END:DAYLIGHT
   BEGIN:STANDARD
   DTSTART:20001026T020000
   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
   TZNAME:EST
   TZOFFSETFROM:-0400
   TZOFFSETTO:-0500
   END:STANDARD
   END:VTIMEZONE
   BEGIN:VEVENT
   UID:20010712T182145Z-123401@example.com
   DTSTAMP:20120201T203412Z
   DTSTART;TZID=America/Montreal:20120206T100000
   DURATION:PT1H
   RRULE:FREQ=WEEKLY
   SUMMARY:Planning Meeting
   ORGANIZER:mailto:cyrus@example.com
   ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@exampl
    e.com
   ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:arnaudq@exam
    ple.com
   ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:mike@exa
    mple.com
   ATTACH;MANAGED-ID=97S;FMTTYPE=text/html;SIZE=80;
    FILENAME=agenda.html:https://cal.example.com/attach/65/34X22R
   END:VEVENT
   END:VCALENDAR

The organizer has a more specific agenda for the 20th of February meeting 🗓️ It gets added to that one particular instance by specifying the "rid" query parameter. The overridden instance is created with the "RECURRENCE-ID" property value matching the value of the "rid" query parameter in the request 🎯 Also, the server takes significant time to finish this request, so it lets the client know about that 🐢

Request

  POST /events/65.ics?action=attachment-add&rid=20120220T100000 HTTP/1.1
  Host: cal.example.com
  Content-Type: text/html; charset="utf-8"
  Content-Disposition: attachment;filename=agenda0220.html
  Content-Length: 105
  If-Match: "123456789-000-111"
  Expect: 100-continue
  Prefer: return=representation


   >> Interim Response <<

   HTTP/1.1 100 Continue


   >> Request Body <<

   <html>
     <body>
       <h1>Agenda</h1>
       <p>Something different, for a change</p>
     </body>
   </html>


   >> Interim Response <<

   HTTP/1.1 102 Processing


   >> Final Response <<

   HTTP/1.1 201 Created
   Content-Type: text/calendar; charset="utf-8"
   Content-Length: 1661
   Content-Location: https://cal.example.com/events/65.ics
   ETag: "123456789-000-222"
   Cal-Managed-ID: 33225
   BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Server//EN
   BEGIN:VTIMEZONE
   LAST-MODIFIED:20040110T032845Z
   TZID:America/Montreal
   BEGIN:DAYLIGHT
   DTSTART:20000404T020000
   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
   TZNAME:EDT
   TZOFFSETFROM:-0500
   TZOFFSETTO:-0400
   END:DAYLIGHT
   BEGIN:STANDARD
   DTSTART:20001026T020000
   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
   TZNAME:EST
   TZOFFSETFROM:-0400
   TZOFFSETTO:-0500
   END:STANDARD
   END:VTIMEZONE
   BEGIN:VEVENT
   UID:20010712T182145Z-123401@example.com
   DTSTAMP:20120201T203412Z
   DTSTART;TZID=America/Montreal:20120206T100000
   DURATION:PT1H
   RRULE:FREQ=WEEKLY
   SUMMARY:Planning Meeting
   ORGANIZER:mailto:cyrus@example.com
   ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@exampl
    e.com
   ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:arnaudq@exam
    ple.com
   ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:mike@exa
    mple.com
   ATTACH;MANAGED-ID=97S;FMTTYPE=text/html;SIZE=80;
    FILENAME=agenda.html:https://cal.example.com/attach/65/34X22R
   END:VEVENT
   BEGIN:VEVENT
   UID:20010712T182145Z-123401@example.com
   RECURRENCE-ID;TZID=America/Montreal:20120220T100000
   DTSTAMP:20120201T203412Z
   DTSTART;TZID=America/Montreal:20120220T100000
   DURATION:PT1H
   SUMMARY:Planning Meeting
   ORGANIZER:mailto:cyrus@example.com
   ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@example.
    com

   ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:arnaudq@exampl
    e.com
   ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:mike@examp
    le.com
   ATTACH;MANAGED-ID=33225;FMTTYPE=text/html;SIZE=105;
    FILENAME=agenda0220.html:https://cal.example.com/attach/65/FGZ225
   END:VEVENT
   END:VCALENDAR

Acknowledgments 🫶

This specification came about via discussions at the Calendaring and Scheduling Consortium. Thanks in particular to Mike Douglass and Eric York 💜

Authors' Addresses ✨

   Cyrus Daboo
   Apple Inc.
   1 Infinite Loop
   Cupertino, CA  95014
   United States of America

   Email: cyrus@daboo.name
   URI:   http://www.apple.com/

   Arnaud Quillaud
   Oracle Corporation
   180, Avenue de l'Europe
   Saint Ismier cedex  38334
   France

   Email: arnaud.quillaud@oracle.com
   URI:   http://www.oracle.com/

   Kenneth Murchison (editor)
   FastMail US LLC
   1429 Walnut St, Suite 1201
   Philadephia, PA  19102
   United States of America

   Email: murch@fastmailteam.com
   URI:   http://www.fastmail.com/

📦 where this page comes from

ietf: rfc8607 2019-06
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms

RFC 8607

Calendaring Extensions to WebDAV (CalDAV): Managed Attachments 🎀

Abstract ✨

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction ✨

1.1. Rationale for Informational Status

2. Conventions Used in This Document 🎀

3. Overview 🌸

3.1. Requirements

3.2. Discovering Support for Managed Attachments 🔍

3.3. POST Request for Managing Attachments 💌

3.3.1. action Query Parameter 🎯

3.3.2. rid Query Parameter 🌸

3.3.3. managed-id Query Parameter 🆔

3.4. Adding Attachments 📎

3.5. Updating Attachments ✨

3.6. Removing Attachments via POST 🗑️

3.7. Adding Existing Managed Attachments via PUT 🧲

3.8. Updating Attachments via PUT 🚫

3.9. Removing Attachments via PUT 🫠

3.10. Retrieving Attachments 📥

3.11. Error Handling 🚨

3.12. Additional Considerations ✨

3.12.1. Quotas 💾

3.12.2. Access Control 🔐

3.12.3. Redirects 🔀

3.12.4. Processing Time ⏳

3.12.5. Automatic Cleanup by Servers 🧹

3.12.6. Sending Scheduling Messages with Attachments 📨

3.12.7. Migrating Calendar Data 🧳

4. Modifications to iCalendar Syntax 🎀

4.1. SIZE Property Parameter 📐

4.2. FILENAME Property Parameter 🗂️

4.3. MANAGED-ID Property Parameter 🆔

5. Additional Message Header Fields 💌

5.1. Cal-Managed-ID Response Header Field 🏷️

6. Additional WebDAV Properties 🌈

6.1. CALDAV:managed-attachments-server-URL Property 🌐

6.2. CALDAV:max-attachment-size Property ✨

6.3. CALDAV:max-attachments-per-resource Property 🌈

7. Security Considerations 🚨

8. IANA Considerations 📋

8.1. Parameter Registrations 🗂️

8.2. Message Header Field Registrations 📮

8.2.1. Cal-Managed-ID 💌

9. References 📚

9.1. Normative References 💖

9.2. Informative References 🧠

Appendix A. Example Involving Recurring Events ✨

Request

Request

Request

Acknowledgments 🫶

Authors' Addresses ✨