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