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

[Julian Reschke <[e-mail]>]

On 2017-05-15 16:03, Ken Murchison wrote:
> 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

Only for creation of the attachment. Once is has been created, it should 
have its own URI, and the usual HTTP methods should be applicable.

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

For adding, I would define an HTTP resource that can be posted to. It 
could be discovered through a WebDAV property.

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

I'm not familiar with 7808. URI templates are superior than hardwiring 
everything for sure. We just shouldn't enforce specific URI templates - 
the server should be able to specify them, clients would need to 
discover them.


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

(see above)

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

I suggest that the attachment *is* a HTTP resource, thus has it's own URI.

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

I'm more concerned about HTTP libraries and intermediaries. See, for 
instance, <http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8170305>.

Best regards, Julian