Extract attachments from iCalendar resources

[wsanchez@…]

If a client writes an iCalendar resource with an attachment in it (encoded inline, rather than referenced by URI), the iCalendar data will be large. This is problematic if the client wishes to make a small (in terms of data size) change to the iCalendar data, such as changing the event title or time, because it will also have to re-upload all of the attachment data as well. A change of a few bytes could end up requiring megabytes (or more) to be sent over the wire.

A solution I'd like to pursue involved the server extracting the attachment from the resource during PUT, parking the attachment in a different location, and rewriting the iCalendar data to reference the attachment resource by URI.

[wsanchez@…]

Here is a summary of what I think the steps involved might be:

1. The client optionally computes an MD5 checksum for the attachment.
2. The client encodes the attachment and inserts it inline in the iCalendar data.
3. The server extracts the attachment and writes it to a new attachment resource.
4. The server rewrites the iCalendar data to reference the attachment via a URL (chosen by the server) to the new attachment resource and writes the modified iCalendar data to the destination iCalendar resource (at the location specified by the client).
5. The server returns a CREATED response to the client.
6. The client reloads the iCalendar resource (using GET) from the server to obtain the data as stored on the server (in this case, it will be different than the client's original data) and its current ETag.
7. The client optionally checks the attachment resource (HEAD request). If the server sends back an MD5 header which matches the MD5 checksum for the original attachment, the client can keep it's current copy of the attachment and associate it with the resource using the ETag given by the server. Otherwise, the client then reloads the attachment (using GET).

[wsanchez@…]

Some reasons why this stragegy is appealing:

• The client sends the event and it's attachments in one request, which means that cleaning up after failures is easier.
• The server takes ownership of managing the attachments. For example:
  • The permissions on the attachment can be inherited from the event, which is generally expected, without the client having to ensure this. Note that there is no way for clients to ask a server to cause one resource to inherit ACEs from another.
  • If the event is deleted or moved to another calendar, etc., the server can delete or move the attachment. Relying on clients to ensure this is highly error prone (eg. a client which doesn't support and knows nothing about attachments does the deleting), which would result in (large!) cruft on the server.

Some reasons why this stragegy is not appealing:

• Some clients get weirded out if the server rewrites their data. The clients are broken. Since CalDAV is new, so are all CalDAV clients, and I assert that forcing them to behave correctly in order to interoperate is OK.
• Clients has to go through a number of steps to ensure they have the correct data.
• Clients have to be thoughtful in order to reduce the over-the-wire traffic when dealing with attachments, including using MD5 sums (or something similar) to avoid reloading unchanged attachment data.
  • This relies on servers to provide MD5 headers; most HTTP servers do not do this, but we can ensure that ours does.