RE: ACL-draft for WebDAV

A "depth" ACE is represented as an inherited ACE in each of the resources
that
it affects.  So if there is an ACE on /dav/tom that is inherited by its
members,
it will appear as an inherited ACE on /dav/tom/mike, /dav/tom/johnson, and 
/dav/tom/tom.txt.

There is no interoperable way in the current ACL spec to *specify* that an
ACE
should be inherited, because techniques for ACE inheritance varies so
widely.
There only is an interoperable way to discover inherited ACE's.

As for DAV:acl-semantics, that is just a way for a client (or for that
matter,
a user) to understand how ACE's are combined or restricted for a given
resource.
They are just a set of token's with predefined meanings that are returned by
a server.  You use PROPFIND on the DAV:acl-semantics property to get the
values
for a particular resource.

Cheers,
Geoff

-----Original Message-----
From: Medha Atré [mailto:medha_atre@persistent.co.in]
Sent: Wednesday, September 26, 2001 4:40 AM
To: WebDAV
Subject: ACL-draft for WebDAV


Hello,
I am going through the ACL draft for building a compliance test harness for
a WebDAV
server. I have some doubts in the same. The draft doesn't mention anything
about the
DEPTH of the ACEs granted to a principal on a particular
collection-resource.
E.g.
	User John has been granted DAV:write ACE to a collection /dav/tom/.
If /dav/tom/ is
containing 3 children namely /dav/tom/mike/, /dav/tom/johnson/ and
/dav/tom/tom.txt,
then what will the access right of John on these three children ? Does
privilege on
particular collection mean same privilege on all of its children to DEPTH
INFINITY or
the user should be granted ACEs separately on each and every child of the
collection
?

I did not understand the significance of ACL SEMANTICS. What is meant by
DAV:first-match, DAV:all-grant-before-any-deny etc. There isn't any example
of XML
request and response given for the same.

Medha Atré
~~~~~~~~~~~~~~~~~~~~
Associate Member of Tech. Staff
Persistent Systems Pvt. Ltd.
Pune, India
Ph : +91-20-5678900 (Ext. 295)
~~~~~~~~~~~~~~~~~~~~

Received on Wednesday, 26 September 2001 07:34:51 UTC