- From: Eric Sedlar <eric.sedlar@oracle.com>
- Date: Wed, 2 May 2001 15:31:47 -0700
- To: "Yaron Goland" <yaron.goland@openwave.com>, "webdav ACL Group" <acl@webdav.org>
- Cc: <w3c-dist-auth@w3.org>
> 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