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

From: Julian Reschke <[email-masked]>
Date: Sun, 14 May 2017 16:23:52 +0200

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.

---

From: Ken Murchison <[email-masked]>
Date: Mon, 15 May 2017 10:03:25 -0400

Hi Julian,

Thanks for the review.  Comments inline.

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

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

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?

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

> 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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 15 May 2017 18:04:28 +0200

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

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

> thing?  Just the keywords?  Did RFC 7808 get this wrong, or is URI

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.

> ...

(see above)

> so), or are you suggesting that the managed-id value be encoded in the

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

> Existing implementations of this CalDAV extension all seem to handle 1xx

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

---

From: Ken Murchison <[email-masked]>
Date: Wed, 17 May 2017 09:07:02 -0400

On 05/15/2017 12:04 PM, Julian Reschke wrote:
> 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.

Using HTTP methods directly on the attachment URI makes things more 
difficult because the calendar resource(s) referencing the attachment 
also need to be updated.  This would have to be done either as a 
side-effect of the PUT/DELETE on the attachment, or as a separate PUT 
(and separate round-trips) on the resource(s).  The desire was to avoid 
doing either one of these, which is why a POST on the calendar resource 
was chosen as the method to add/update/delete an attachment from a 
calendar resource.

> could be discovered through a WebDAV property.

We could certainly define a template or series of templates for 
add/update/delete and expose them as WebDAV properties.

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 17 May 2017 09:51:19 -0400

Hi Ken,

> add/update/delete and expose them as WebDAV properties.

I would be OK with adding that, provided we also include an Appendix that 
describes what currently shipping implementations do - basically what is 
coded into the current spec. i.e., the template allows the same form of 
query param based URIs as we have today.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 17 May 2017 09:53:44 -0400

Hi Ken,

> was chosen as the method to add/update/delete an attachment from a

One tricky aspect here is that calendar servers may not "host" the 
attachments themselves - i.e., they could use a separate "drop box" service 
to store the resources. In that case it is important that changes to the 
attachments are always managed through the calendar server so that it can 
alert clients via changes to the calendar data whenever an attachment is 
added, changed, or removed.

-- 
Cyrus Daboo

---

From: Julian Reschke <[email-masked]>
Date: Wed, 17 May 2017 15:58:00 +0200

> was chosen as the method to add/update/delete an attachment from a

But the POST is *not* on the calendar resource, but on the calendar 
resource + query parameters, which, from HTTP's point of view is a 
different resource already.

Furthermore, what URIs are used is orthogonal to the question of which 
methods to use.

Why is

   POST /calendar-entry?action=remove&attachment=xyz

easier to process than

   DELETE /calendar-entry?attachment=xyz

or

   DELETE /calendar-entry/attachments/xyz

?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 17 May 2017 16:01:20 +0200

On 2017-05-17 15:53, Cyrus Daboo wrote:
> attachments themselves - i.e., they could use a separate "drop box"
> service to store the resources. In that case it is important that
> changes to the attachments are always managed through the calendar
> server so that it can alert clients via changes to the calendar data
> whenever an attachment is added, changed, or removed.

Again, that's an implementation detail. Just because the calendar server 
stores attachments somewhere else doesn't mean it has to expose those URIs.

Best regards, Julian

---

From: Ken Murchison <[email-masked]>
Date: Mon, 22 May 2017 14:59:07 -0400

>   DELETE /calendar-entry/attachments/xyz

The issue here is that a single calendar resource may contain multiple 
events (recurring event with overrides) and a particular attachment may 
be associated with more than one instance of that event.  For this 
reason, we felt it best to use the calendar resource as the gateway to 
the attachments, thus allowing manipulating multiple instances of an 
attachment in a single round-trip.  Also, by preventing clients from 
manipulating attachments directly, a CalDAV server isn't forced to alter 
all calendar resources associated with a particular attachment.

We also have a fairly large number of deployed implementations which we 
do not want to make non-compliant by substantially modifying the 
protocol.  At this point, specifying the use of HTTP methods other than 
POST would indeed make existing implementations non-compliant.

We would definitely like to make this protocol conform to current HTTP 
practice where possible, and would also document where we have strayed 
from existing practice if required to do so.  Do you think we can come 
to some kind of consensus that meets these goals?

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 22 May 2017 15:19:37 -0700

> On May 22, 2017, at 11:59 AM, Ken Murchison <[email-masked]> wrote:
>> But the POST is *not* on the calendar resource, but on the calendar resource + query parameters, which, from HTTP's point of view is a different resource already.
>> 
>> Furthermore, what URIs are used is orthogonal to the question of which methods to use.
>> 
>> Why is
>> 
> The issue here is that a single calendar resource may contain multiple events (recurring event with overrides) and a particular attachment may be associated with more than one instance of that event.  For this reason, we felt it best to use the calendar resource as the gateway to the attachments, thus allowing manipulating multiple instances of an attachment in a single round-trip.  Also, by preventing clients from manipulating attachments directly, a CalDAV server isn't forced to alter all calendar resources associated with a particular attachment.

But that isn't relevant to the choices here.  HTTP is not a filesystem.
A single implementation (e.g., caldav resource) can handle a wide variety
of URLs (identified HTTP resources) with all sorts of co-dependencies in
the state represented by those resources.  They are all part of the calendar.
The method states the kind of action being made.

Likewise, an identifier for the attachment associated with the calendar entry
doesn't have to be the same as the identifiers for interacting with the
attachment directly.  For example, the calendar might provide one identifier
for the original attachment, a second for the attachment currently applicable
to a given instance of an entry, and a third for updating future instances
of that repeating event (i.e., all defined by the server, not the protocol).

In any case, one of the cornerstones of caldav practice is that caldav
provides just one interface to an abstract Calendar database normally
accessed via many different protocols/systems.  The Calendar should already
be maintaining coherence between entries and attachments, just like it
shouldn't require a new entry be created every time the invitation list
is expanded.

> We also have a fairly large number of deployed implementations which we do not want to make non-compliant by substantially modifying the protocol.  At this point, specifying the use of HTTP methods other than POST would indeed make existing implementations non-compliant.

Specifying method actions within URL query strings is well-known to be
bad practice. However, if you are okay with specifying an IETF protocol
that contains obviously bad practice in its application of HTTP,
a minimum would be to reference section 4.2.1 of RFC7231, where it states:

   When a resource is constructed such that parameters within the
   effective request URI have the effect of selecting an action,
   it is the resource owner's responsibility to ensure that the action
   is consistent with the request method semantics. For example, it is
   common for Web-based content editing software to use actions within
   query parameters, such as "page?do=delete". If the purpose of such a
   resource is to perform an unsafe action, then the resource owner MUST
   disable or disallow that action when it is accessed using a safe
   request method. Failure to do so will result in unfortunate side
   effects when automated processes perform a GET on every URI reference
   for the sake of link maintenance, pre-fetching, building a search index, etc.

> We would definitely like to make this protocol conform to current HTTP practice where possible, and would also document where we have strayed from existing practice if required to do so.  Do you think we can come to some kind of consensus that meets these goals?
> 
> -- 
> Kenneth Murchison

I honestly don't see how this can be considered an extension of WebDAV
and yet have such a profound misunderstanding of method semantics.
Other applications of HTTP might be expected to work around PUT/DELETE,
but not a WebDAV server.

Likewise, defining a protocol in terms of predefined URL patterns and
specific query components is fundamentally incompatible with REST.

OTOH, it's not the first time this has come up.  HTTP provides plenty
of rope, for good reasons, and these types of choices seem only to
harm those using the rope.  Maybe a future version will just use HTTP.

Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <https://www.adobe.com/>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 23 May 2017 11:47:04 +0200

> all calendar resources associated with a particular attachment.

But that's a detail of how the server implements these resources. I 
still do not understand how the choice of HTTP methods and URI formats 
is relevant for that.

> POST would indeed make existing implementations non-compliant.

Yes.

> to some kind of consensus that meets these goals?

I'm just offering my feedback from an HTTP and web architecture point of 
view. And from that angle, the protocol as specified violates multiple 
best practices, and I would recommend not to publish it on the standards 
track. "Informational" might work, if this is indeed what's implemented, 
and implementers are unwilling to put more work into it...

Best regards, Julian