Re: [art] ART Area Review for draft-ietf-calext-caldav-attachments-02

[Ken Murchison <[e-mail]>]

Hi Julian,

Thanks for the review.  Comments inline.


On 05/14/2017 10:23 AM, Julian Reschke wrote:
> 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.

The resource being acted upon is an actual calendar resource, which is 
already in place.  The attachments are meta-data associated with one or 
more calendar resources, which is why a POST is used on the calendar 
resource to manipulate an attachment.  Can you explain how you would 
envision different HTTP methods be used to add/update/delete an 
attachment associated with a calendar resource?

> 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.

Which part(s) of the query syntax MUST not be specified?  The entire 
thing?  Just the keywords?  Did RFC 7808 get this wrong, or is URI 
templating ok?


> 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.

As above, can you explain how different HTTP methods would be used where 
the target of the add/update/remove operation is an existing calendar 
resource?



> 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).

Can parameters be added to a Location header field (it doesn't appear 
so), or are you suggesting that the managed-id value be encoded in the 
URI-reference value?



>
> 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.

Existing implementations of this CalDAV extension all seem to handle 1xx 
status codes.


-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University