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/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




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