Last Call Review of draft-ietf-calext-caldav-attachments-02
review-ietf-calext-caldav-attachments-02-artart-lc-reschke-2017-05-17-00

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.