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

[Ken Murchison <[e-mail]>]

On 05/17/2017 09:58 AM, Julian Reschke wrote:
> On 2017-05-17 15:07, Ken Murchison 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.
>
> 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
>
> ?

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?

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University