On 2017-05-17 15:53, Cyrus Daboo wrote:
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.
One tricky aspect here is that calendar servers may not "host" the
attachments themselves - i.e., they could use a separate "drop box"
service to store the resources. In that case it is important that
changes to the attachments are always managed through the calendar
server so that it can alert clients via changes to the calendar data
whenever an attachment is added, changed, or removed.
Again, that's an implementation detail. Just because the calendar server
stores attachments somewhere else doesn't mean it has to expose those URIs.
Best regards, Julian