On 05/15/2017 12:04 PM, Julian Reschke wrote:
On 2017-05-15 16:03, Ken Murchison wrote:
Hi Julian,
Thanks for the review. Comments inline.
On 05/14/2017 10:23 AM, Julian Reschke wrote:
Reviewer: Julian Reschke
Review result: Not Ready
Document: draft-ietf-calext-caldav-attachments-02
IETF LC End Date: 2017-05-14
IESG Telechat date: 2017-05-25
This document describes attachment handling in CalDAV (WebDAV based
calendaring).
The mechanism described by this document is essential RPCish, using
HTTP POST for tunneling. It will work in practice, but it definitively
isn't state of the art in IETF protocols, in particular in an
otherwise WebDAV/CalDAV-based ecosystem.
Major issues:
The main issue with this specification is that it
1) models operations on attachments as POST operations, where the
actual type of operation is specified using a query parameter, instead
of using the HTTP methods POST, PUT, and DELETE.
The resource being acted upon is an actual calendar resource, which is
already in place. The attachments are meta-data associated with one or
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.
more calendar resources, which is why a POST is used on the calendar
resource to manipulate an attachment. Can you explain how you would
envision different HTTP methods be used to add/update/delete an
attachment associated with a calendar resource?
For adding, I would define an HTTP resource that can be posted to. It
could be discovered through a WebDAV property.
We could certainly define a template or series of templates for
add/update/delete and expose them as WebDAV properties.
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University