RE: [ACL] Reviewing the ACL Spec - Semantics

> 1	Semantics as a Property
>
> The information contained in the semantics property describes information
> about the type of a resource. This is exactly the type of information RFC
> 2518 requires to be placed in the resource type. Therefore I move that the
> semantics property be removed and this data be supplied in the
> resource type
> property. Please also refer to my e-mail on IsPrincipal.

I don't have a problem with allowing dav:resourcetype to list all of the
abstract interfaces that a resource supports, as I mentioned in my last
mail.  However, this should only be done as part of a general RFC2518
revision, IMHO.

> 2	Semantics on any ACL'd Resource
>
> The values in the semantics property do a good job of capturing
> most of the
> axis's of functionality but a few were missed. I list below those I could
> find.
>
> Principals Identified by HTTP URL - Does the resource require that all
> principals it uses are referenced by at least one HTTP URL? Hopefully the
> need for this extension to the semantics section will go away when the
> specification is changed to mandate support for HTTP URLs. Please
> also refer
> to my e-mail on multiple principals.
>
> Allows Group Principals - Will the resource support principal references,
> either in ACEs or for owner, that contain group principals?
>
> Recursive Principals - Will the resource support principal references,
> either in ACEs or for owner, that contain group principals that allow
> recursive principals?
>
> Inheritance Policy - Semantic information is needed on what sort of
> inheritance policy the resource follows. At a minimum we should
> specify the
> Windows NT, Oracle and popular UNIX policies. Given that
> representatives of
> both Microsoft and Oracle are authors on the spec and given the number of
> working group members familiar with UNIX, I assume that the
> expertise exists
> in the group to build these descriptions.
>
> Write-able Owner - The Owner property may or may not be write-able. This
> information needs to be specified in the semantics. Hopefully we
> will adopt
> a method to modify owner. If so then no value is necessary in the
> semantics
> section because OPTIONS will list if the owner modification method is
> supported.

The original intent of the semantics property was to allow clients to
be able to evaluate an ACL, or give the user some clue as to how the
ACL will be evaluated by the server, so the client knows how to author
them.  It wasn't intended as a general capabilities discovery method.

As far as your specific suggestions, my take is:

* Recursive groups:  this is getting into the area of user/group admin,
			which we are explicitly trying to stay out of.  We also
			don't allow you to ask all of the groups you are a member
			of.  I'm not sure there is a lot of support for going into
			this area in the first rev of the spec.  However, if we
			were to do so, we could add either a <dav:isRecursive>
			property to principal collections or make that a defined
			element tag allowed in <dav:resourcetype> (as per that
			discussion).

* Inheritance policy:  the only people who cared about this were me (Oracle)
			& Anne Hopkins (Microsoft), and Anne recently left Microsoft.
			Our implementations were different enough that it would be
			good to see what other people wanted before doing something
			interoperable here so we deferred this to a later "Advanced"
			spec.

* The list of writeable properties may or may not include owner, but this is
			a general RFC2518 problem.  Perhaps we should have a property
			that lists writeable property names rather than trying to put
			the list of writeable live properties in the spec.

> 3	Semantics specific to Group Principals
>
> Recursive Principals - Will this group principal allow recursive principal
> membership?
>

See above comment.

> 4	Semantics specific to Collections
>
> Default ACL Policy - We need to add semantic information to collections
> specifying the ACLs that will appear when a child is created. The default
> ACL is not necessarily defined exclusively by inheritance. I vaguely
> recollect systems that allow users to specify additional default ACEs. For
> example, an administrator can add default ACEs that specify that all new
> resources are read-only, except by their owner.
> 	BTW, can users safely assume that the inheritance policy
> specified on the
> collection will also apply to its children? If not, then we need
> to specify
> what inheritance policy applies to the children as part of the default ACL
> policy value. We can provide this information for the root "/" of a server
> by accessing the reserved "*" URL.
>

There are way too many ways to specify the default ACL to get good
interoperability.
You can specify a default ACL per user (like the Unix UMASK).  You can
specify
a default ACL per directory (Apache allows this).  You can specify a default
ACL by type (Principals have this default ACL).  Perhaps each user wants to
specify their own ACL for a particular type (when I create a particular type
of resource, it should have this ACL).  That's why I think we should defer
this
to the "Advanced" spec.


> 5	ERROR CODES
>
> We need to specify error codes specific to violating each of the semantics
> we specify. Geoff has more notes about this issue and what format
> we should
> use.
>

If we extend <dav:resourcetype> to list the set of supported interfaces on
the resource, we probably need a "Interface <blah> not supported" error
code.

Received on Wednesday, 2 May 2001 18:27:50 UTC