- From: Werner Donné <werner.donne@re.be>
- Date: Mon, 07 May 2007 13:53:06 +0200
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: acl@webdav.org, WebDAV <w3c-dist-auth@w3.org>
There is another problem with not being able to identify an ACE. Inheritance won't work. Consider the following scenario: resource1 has an ACL with one ACE: "grant read to Jack". resource2 inherits this ACE. Now the ACL of resource1 is changed to have two ACEs: "grant read to John" and "grant read to Paul". What should happen to resource2? There seem to be three possibilities: 1) Jack became John and Paul was added, resource2 continues to inherit the ACE. 2) Jack became Paul and John was added, resource2 continues to inherit the ACE. 3) Jack was removed and John and Paul were added, resource2 loses the inherited ACE. Werner. Julian Reschke wrote: > > Werner Donné wrote: >> I have read that paragraph, but it doesn't solve much. What happens >> if the client leaves the protected and inherited ACEs in the acl >> element? From the evaluation procedure it follows there is an order >> in the ACEs. Since protected and inherited ACEs do not necessarily >> come first, they have to be included in the request body of the ACL >> method. Leaving them out would require a way to match old and new >> ACEs in order to find back the correct positions. > > Yes, agreed (now that you mention it :-). > >> On the other hand, if protected and inherited ACEs are not allowed >> to be present, there should be corresponding preconditions for the >> ACL method. > > I have to confess that I'm not sure what the spec tries to say here, nor > how it is implemented in practice. > > This definitively requires research and feedback from implementors. > > Best regards, Julian > > -- Werner Donné -- Re Engelbeekstraat 8 B-3300 Tienen tel: (+32) 486 425803 e-mail: werner.donne@re.be
Received on Monday, 7 May 2007 11:52:59 UTC