Reviewer: Julian Reschke
Review result: Not Ready
Document: draft-ietf-calext-caldav-attachments-02
IETF LC End Date: 2017-05-14
IESG Telechat date: 2017-05-25
This document describes attachment handling in CalDAV (WebDAV based
calendaring).
The mechanism described by this document is essential RPCish, using HTTP
POST for tunneling. It will work in practice, but it definitively isn't
state of the art in IETF protocols, in particular in an otherwise
WebDAV/CalDAV-based ecosystem.
Major issues:
The main issue with this specification is that it
1) models operations on attachments as POST operations, where the actual
type of operation is specified using a query parameter, instead of using
the HTTP methods POST, PUT, and DELETE.
2) hardwires specific query strings into the protocol, violating a MUST
level requirement in BCP 190 (see
https://tools.ietf.org/html/rfc7320#section-2.4):
Applications MUST NOT directly specify the syntax of queries, as this
can cause operational difficulties for deployments that do not
support a particular form of a query. For example, a site may wish
to support an application using "static" files that do not support
query parameters.
Re 1) this is even called out specifically in Sections 3.8 (update) and
3.9 (remove), but it's not clear at all why that is the case.
Re 2) Part of the hard-wiring could be avoided by using different HTTP
methods for the different actions. The other parameters could be made
discoverable using URIs / URI templates, exposed as WebDAV properties,
as is the case in RFC 5995.
5.1. Cal-Managed-ID Response Header Field
This doesn't seem to address the points listed in
<https://greenbytes.de/tech/webdav/rfc7231.html#considerations.for.new.header.fields>
(and it wouldn't be needed if the attachment would be modeled as an HTTP
resource whose values could be reported back in a Location header field
upon creation).
Minor issues:
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.
While discussing the new code 103 in the HTTP WG, we considered interop
problems with existing code that doesn't handle 1xx status codes at all,
or had problems with status codes other than 100. I personally support
use of new 1xx status codes, but it would be good to hear whether the WG
considered deployment problems when making this a SHOULD-level requirement.
3.12.5. Automatic Clean-up 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.
This essentially requires servers to distinguish between resources that
never have been there, and those which have been there but were removed.
It's definitively additional work for the server, where it's not clear
what the benefit for clients is.
6.1. CALDAV:managed-attachments-server-URL property
This mechanism is really funky. Depending on the presence of this
property, the authority part of attachment URIs is rewritten or not.
Depending on its contents, the rewrite is based on yet another default
or the given value.
It's not clear why all this can't be replaced by a mechanism where
attachment URIs can be relative references to be resolved against a base
URI.
Nits/editorial comments:
In addition, such a server MUST support the "return=representation"
Prefer header field value [RFC7240] on successful HTTP PUT and POST
requests targeting existing calendar object resources, by returning
the new representation of that calendar resource (including its new
ETag header field value) in the response.
(not specific to this spec, but to the CalDAV ecosystem: the specs rely
a lot on DAV feature names, but there's no registry - I believe it would
be good if we added one in a separate spec)
1. Introduction
The iCalendar [RFC5545] data format is used to represent calendar
data and is used with iTIP [RFC5546] to handle scheduling operations
between calendar users.
[RFC4791] defines the CalDAV Calendar Access protocol, based on HTTP
[RFC7230], for accessing calendar data stored on a server.
Maybe also mention RFC 4918 here. RFC 4918 currently isn't referenced at
all, despite the fact that the specification relies on stuff defined
over there, such as the "DAV" response header field.