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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]