- From: Tim Olsen <tolsen718@gmail.com>
- Date: Sat, 5 May 2007 21:36:10 -0400
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: werner.donne@re.be, acl@webdav.org, WebDAV <w3c-dist-auth@w3.org>
In the implementations we're working on here at Lime Wire, we always put the protected ACEs up front and the inherited ACEs last. This way one cannot override a protected ACE - with the exception of protected ACEs that are inherited because they get grouped together with the inherited ACEs. -Tim On 5/5/07, Julian Reschke <julian.reschke@gmx.de> 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 > > >
Received on Sunday, 6 May 2007 01:36:13 UTC