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

[Cyrus Daboo <[e-mail]>]

Hi Ken,

--On May 17, 2017 at 9:07:02 AM -0400 Ken Murchison <[e-mail]> 
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.

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