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

[Julian Reschke <[e-mail]>]

On 2017-05-22 20:59, Ken Murchison wrote:
> ...
> 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's a detail of how the server implements these resources. I 
still do not understand how the choice of HTTP methods and URI formats 
is relevant for that.

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

Yes.

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

I'm just offering my feedback from an HTTP and web architecture point of 
view. And from that angle, the protocol as specified violates multiple 
best practices, and I would recommend not to publish it on the standards 
track. "Informational" might work, if this is indeed what's implemented, 
and implementers are unwilling to put more work into it...

Best regards, Julian