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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Ken,

--On May 17, 2017 at 9:07:02 AM -0400 Ken Murchison <murch@xxxxxxxxxxxxxx> 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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]