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