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

[Ken Murchison <[e-mail]>]

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

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.



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

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


-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University