- From: -=jack=- <jack@twaxx.twaxx.com>
- Date: Wed, 2 Jul 1997 13:42:35 -0700
- To: jradoff@novalink.com, Judith Slein <slein@wrc.xerox.com>, w3c-dist-auth@w3.org
I agree with the requirements Judith has listed almost completely, with the following exceptions: slein@wrc.xerox.com: ---------------------- 5. At a minimum, WebDAV should provide for access control over listing the contents of a collection, reading resources [read locked / read unlocked -- I don't think we should make this distinction], modifying resources, deleting resources, and changing access control permissions on a resource. ---------------------- I've thought about this for quite a while, but I really wonder whether read locks are really very meaningful. There are some subtle areas in which they can provide the user with clearer or more information, but in general I find the idea somewhat meaningless. I believe simply the ability to access an object is of much greater importance. Because the ability to grant access to web based objects should extend to collections and listings thereof, I agree that access control should be provided for listing collection contents, modifying and deleting objects, and for changing access control permissions, but I just don't really think that the read lock idea is anywhere near as valuable, and I also tend to think that simplicity is generally the best policy wherever possible. slein@wrc.xerox.com: ----------------- I don't really like Jim's suggestion of "data producing process" for "Web Application". These applications do typically return data to browsers, sometimes dynamically created, but they might just be interfaces to document management systems with their own access control policies or workflow management systems (groupware) that help users define access control over the life cycle of a document. Maybe "server-based application". ----------------- I agree that "data producing process" is not appropriately descriptive of what web based applications really may be as time goes on and more sophisticated applications continue to appear. Particularly because this is an area quite closely related to groupware and document management systems (an area of some expertise for me), this tends to be a little misleading I think. I like "server based application" much, much better... slein@wrc.xerox.com: ----------------- In any case, I'm not sure we should require WebDAV servers to provide access control at all, much less this particular list of categories. I guess I think of a set of categories like the one you propose as similar to metadata schemas. There could be lots of different access control schemas, each defined in a resource somewhere, and servers could make it known which schema(s) they support. ----------------- I tend to agree with the above sentiments. I think it's a better approach to have the servers be able to make it known what schemas they support, as the schemas themselves will probably mature and change over time as people use this kind of software. This approach will allow for this process in a more flexible way it would appear. slein@wrc.xerox.com: ------------------ Controlling who can PUT doesn't let you distinguish between who can create and who can modify, for example. Who can modify metadata vs. who can modify content. Who can modify which metadata. In a database application, who can modify which fields in a record. ------------------ This is true, and it's conceivable that server vendors may not get to the level of detail required for our purposes here. Since content and it's related meta data can be arbitrarily complex (and with things like XML it's conceivable that they will become more complex, and that the access control issues may grow in complexity with the content, particularly if people start building applications that operate upon meta data and structural information such as that found in XML, etc.), it would seem that what will serve best would be to have the WEBDAV functionality positioned such that the server could be queried to find out supported functionality in a similar way as with querying for schemas as described earlier. I also agree that it is preferable to separate locking from access control... Just my two cents. -=jack=- (This text composed by voice) --
Received on Wednesday, 2 July 1997 16:43:34 UTC