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

[Julian Reschke <[e-mail]>]

On 2017-05-17 15:53, Cyrus Daboo wrote:
>> 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.

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