We believe that's the case. :-) That is, we've implemented it, and have some tests, but since we lack real clients that use it, it's hard to know for sure that the implementation is satisfactory as-is. Obviously, we'd love to see that change. Note that some resources do not allow editing of ACLs. This may be true for some of the base hierarchy (eg /calendars), since we don't necessarily want to let those get into a "broken" state. Additionally, your home calendar will give you DAV:all access which is protected, meaning that you can't (that is, shouldn't be, unless there is a bug) remove that privilege from a calendar home's owner. The strategy that we've been pursuing to date in regarding ACL controls for calendar resources and their containers is to avoid doing ACL operations on individual calendar resources, and stick to editing ACLs for calendar collections. The server will allow you to do either, but I will bet that this will confuse some, if not many, clients. ACLs are presently still a pretty bleeding-edge concept, and I think getting too funky with them may be tricky. So things like giving a friend read access to a calendar should be straighforward, but doing that for individual events has a lot of oddball corner-case issues, I think. We think the server does sane things here, but again, without real use cases, it's hard to know for sure, and I don't expect that clients will necessary cope well. Note also that we have a notion of "proxy groups". Each principal on the server has two such groups associated with it, a read proxy group, and a read/write proxy group. The ACLs are already set up appropriately for these groups on each calendar collection, on the theory that editing the group membership is simpler than monkeying with ACLs. Again, real-world usage will bear out how well that works. One limitation is that this applies to all of your calendars, and not just some. Hope this helps. -wsv On May 30, 2007, at 12:36 AM, mwacker@linagora.com wrote:
Do you mean that CalDAV ACL are already implemented on the server side ? As far as i remember CalDAV ACLs are applicable not only on a calendar object (which is a collection of events in webdav speaking) but ACLs can be set event by event. Does Darwin Calendar Server implement this fully ?
The only problem to exploit this come from client side ?
— Wilfredo Sánchez - wsanchez@wsanchez.net