Hi, I'm a little puzzled by the change in this ticket to completely remove the ACL method. I realize that it'll make it easier for a specific application of calendarserver, in which the client doesn't offer ACL control and access is defined by predefined group or proxy principals, but it would make the calendarserver a lot less general a tool. It would also conflict with rfc4791 section 2. What are the arguments for doing this ? - aside from not having to solve the original problem i ticket 148. /Peter
On Nov 18, 2009, at 4:47 AM, Peter Mogensen wrote:
I'm a little puzzled by the change in this ticket to completely remove the ACL method. I realize that it'll make it easier for a specific application of calendarserver, in which the client doesn't offer ACL control and access is defined by predefined group or proxy principals, but it would make the calendarserver a lot less general a tool.
Calendar Server isn't a general-purpose DAV server; it's a calendar service.
It would also conflict with rfc4791 section 2.
Yeah... We wouldn't be removing the ACL method altogether, but we would be returning a FORBIDDEN response to any attempts to change the ACLs of resources that are managed by the calendar system. It's legal for a server to disallow that and still comply with RFC 3744. We will still advertise the ACL properties, which will allow clients to see what access they have.
What are the arguments for doing this ? - aside from not having to solve the original problem i ticket 148.
The problem with the ACL method is that it's practically impossible for a client to implement it correctly such that it works with any server, due to the arbitrarily-definable privileges and hierarchy. It's just too complex to be useful. -wsv
participants (2)
-
Peter Mogensen
-
Wilfredo Sánchez Vega