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

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

 





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




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