WebDAV conference call May 5, 2000: 11am - 12:00 pm Attendees: Barry Lind - Xythos Anne Hopkins - Microsoft Eric Sedlar - Oracle (taking notes) Geoff Clemm - Rational Bernard Chester--?? Resolved: * ACL spec does not need to address the issue of the default ACL for newly created resources, since the rules will be implementation-specific, and the client can always check the resource later to see what ACL was used * If MOVE cannot keep the ACL used in the previous location, the MOVE should fail. COPY should work the same way as a PUT + PROPPATCH. * ACEs should have an element called (or something) that has the URL of a resource that, when updated, can be used to change the value of this ACE. (Note that NT provides ACL inheritance at effectively the ACE level). Open Issues: Description Action What support is needed for container-based ACL sharing (cf. Bernard) N/A Do we want to remove ACL as a property, since finding the source resource for ACEs can be expensive (current NT implementations)? (Possibly reinstate the ACL method as a way to read as well as set ACLs, since the property is probably all that is normally needed) N/A Need detail on how updating the source_resource will work N/A ACLs that are resources have locking implications N/A Report on resources using an ACL Discussion: * ACL inheritance (from the version 0 spec) covered two areas: default ACL on new resources, and ACL sharing (and ACE sharing) * There are clearly many methods for choosing the default ACL for a resource (inheritance from the container, based on the type of document, based on user-session information (e.g. UMASK), based on a property on the container, etc.), and there is really no commonality between them. Nobody had any objections to omitting this from the document. * Users & clients need to know the implications of updating an ACL, which is why the methods of sharing need to be in the spec * There are basically two types of ACL sharing we are dealing with: ACLs inherited from some other resource (but still a part of that resource), and ACLs that are really independent resources in themselves. Geoff's source_resource for ACE proposal addresses both situations, since what the client needs to know is where to go to update that ACL * Discussion on the need for a report of all of the resources who share an ACL (in total or in part). Discussion of DASL for this. Geoff points out that if DASL finishes before we do, any REPORT can be easily removed. No resolution on this. * Anne & Eric concluded with a discussion on the implications of the cost of computing the source_resource. o Anne proposes making a special method to find the source_resource o Since the property shows a user what s/he can do, there is no need for a client to see the ACL unless they are going to update it later. Therefore, perhaps the solution is just to make the ACL reading part of a separate method, so that any PROPFIND of or won't do this calculation