W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2007

Re: [ACL] RFC 3744: Modifying ACEs

From: Tim Olsen <tolsen718@gmail.com>
Date: Sat, 5 May 2007 21:36:10 -0400
Message-ID: <4be80d840705051836ia18264w2a0a5dd943c258bc@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:15 GMT