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

["Roy T. Fielding" <[e-mail]>]

> On May 22, 2017, at 11:59 AM, Ken Murchison <[e-mail]> wrote:
> 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.

But that isn't relevant to the choices here.  HTTP is not a filesystem.
A single implementation (e.g., caldav resource) can handle a wide variety
of URLs (identified HTTP resources) with all sorts of co-dependencies in
the state represented by those resources.  They are all part of the calendar.
The method states the kind of action being made.

Likewise, an identifier for the attachment associated with the calendar entry
doesn't have to be the same as the identifiers for interacting with the
attachment directly.  For example, the calendar might provide one identifier
for the original attachment, a second for the attachment currently applicable
to a given instance of an entry, and a third for updating future instances
of that repeating event (i.e., all defined by the server, not the protocol).

In any case, one of the cornerstones of caldav practice is that caldav
provides just one interface to an abstract Calendar database normally
accessed via many different protocols/systems.  The Calendar should already
be maintaining coherence between entries and attachments, just like it
shouldn't require a new entry be created every time the invitation list
is expanded.

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

Specifying method actions within URL query strings is well-known to be
bad practice. However, if you are okay with specifying an IETF protocol
that contains obviously bad practice in its application of HTTP,
a minimum would be to reference section 4.2.1 of RFC7231, where it states:

   When a resource is constructed such that parameters within the
   effective request URI have the effect of selecting an action,
   it is the resource owner's responsibility to ensure that the action
   is consistent with the request method semantics. For example, it is
   common for Web-based content editing software to use actions within
   query parameters, such as "page?do=delete". If the purpose of such a
   resource is to perform an unsafe action, then the resource owner MUST
   disable or disallow that action when it is accessed using a safe
   request method. Failure to do so will result in unfortunate side
   effects when automated processes perform a GET on every URI reference
   for the sake of link maintenance, pre-fetching, building a search index, etc.

> 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

I honestly don't see how this can be considered an extension of WebDAV
and yet have such a profound misunderstanding of method semantics.
Other applications of HTTP might be expected to work around PUT/DELETE,
but not a WebDAV server.

Likewise, defining a protocol in terms of predefined URL patterns and
specific query components is fundamentally incompatible with REST.

OTOH, it's not the first time this has come up.  HTTP provides plenty
of rope, for good reasons, and these types of choices seem only to
harm those using the rope.  Maybe a future version will just use HTTP.


Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <https://www.adobe.com/>