Subject: Re: [ACL] DAV:unauthenticated usage

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 13 Apr 2004 07:31:33 -0400

Our experience is that
Getting consensus on each new addition of this kind is very difficult,
because everyone does this kind of thing very differently.
So I'd want to save these kind of enhancements until
after we have more practical experience with the features we
were able to get consensus on.

Cheers,
Geoff

Stefan wrote on 04/13/2004 04:37:48 AM:

> 
> Am 09.04.2004 um 22:57 schrieb Eric Sedlar:
> 
> > Well, not to be a pain in the butt, but actually now that our 
> > implementation
> > teams have been looking seriously at the spec, we have a couple 
> > additional
> > issues:
> >
> > * shared ACLs:  the current spec specifies that the <acl> property 
> > from the
> > resources listed in <inherited-acl-set> is to be used.  The problem 
> > with
> > this is when you want a different acl to be propagated to the 
> > inheritees
> > than you want on the parent resource.  This could be solved by 
> > defining an
> > <acl-data> property, which had the same structure as <acl>, but 
doesn't
> > define access control for the parent resource.  Another issue in this
> > scenario is that <inherited-acl-set> needs to be PROPPATCH'able.  A 
> > number
> > of our WebDAV servers at Oracle only support ACLs by reference from 
the
> > resource rather than one copied to each resource, so this is a 
problem.
> 
> There is nothing in the spec which says that DAV:inherited-acl-set 
> cannot be
> PROPPATCHed.
> 
> As to special inheritance with <acl-data>: The spec does not define how
> acl inheritance is done by the server (e.g. if acls default to parent 
> resource
> or something else). Your server could implement inheritance by some
> <oracle:acl-data> and still be compliant with the spec.
> 
> 
> > * usability:  One of the major use cases for WebDAV ACL is an 
> > interoperable
> > client setting access permissions on objects on any compliant servers 
> > (e.g.
> > via a GUI).  One complaint I've received is that creating ACLs is too
> > complicated.  This is why Windows provides for a small set of 
> > pre-defined
> > useful ACLs, and I think most servers will want to do the same.
> > Potentially, the set of pre-defined ACLs could vary per resource.  It 
> > would
> > be useful to have an additional live property with a URL of a 
> > collection of
> > resources (or else to list the set of URLs in that property) with
> > pre-configured ACLs (e.g. "Public Read/Owner Write", "Private",
> > "Classified", "Oracle Database Development Group Shared Docs", etc.). 
> > These
> > ACLs could then be copied by value into the ACL of that resource, or
> > referenced by using inherited-acl-set for truly shared access control
> > policies.
> 
> As I understood your description this seems to be outside the scope of
> the current spec. Offering default ACL-building blocks for the UI is 
> good
> for user experience, but I would not put it into the basic ACL spec.
> 
> I can think of tons of things which we could invent and improve on 
> regarding
> ACL management and UI experience, but let's leave the spec at its 
> current
> scope and collect implementation experience before defining more
> standardized elements and behaviour.
> 
> //Stefan
> 
> >
> > --Eric
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of
> >> Julian Reschke
> >> Sent: Thursday, April 08, 2004 2:08 PM
> >> To: [email-masked]
> >> Subject: Re: [ACL] DAV:unauthenticated usage
> >>
> >> Geoff & Eric,
> >>
> >> thans for answering the questions.
> >>
> >> We still haven't reached the AUTH48 period for the RFC, so if there 
> >> are
> >> REALLY REALLY minor edits we should do on the spec, let me know.
> >>
> >> On the other hand, if there's a major problem we can't fix right now,
> >> let's at least identify it so we can put it on a future RFCxxxx-bis
> >> issues list.
> >>
> >> Regards, Julian
> >>
> >> --
> >> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >> _______________________________________________
> >> acl mailing list
> >> [email-masked]
> >> http://mailman.webdav.org/mailman/listinfo/acl
> >
> > _______________________________________________
> > acl mailing list
> > [email-masked]
> > http://mailman.webdav.org/mailman/listinfo/acl
> 
> 
> _______________________________________________
> acl mailing list
> [email-masked]
> http://mailman.webdav.org/mailman/listinfo/acl