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







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