Re: Access Control Preliminary Draft

At 01:42 PM 7/2/97 PDT, -=jack=- wrote:
>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.
>

I think to some extent you, Jon, and I are probably talking past each other
here.  I don't think anyone has proposed that we define read locks as part
of WebDAV (although I personally think they would be useful -- if we
understand a read lock as one that prevents anyone from putting a write lock
on the resource).

What I think Jon suggested was that there be two sorts of read access
permission:  One would let you read a resource only when it has no (write)
locks on it.  The other would let you read a resource even if it has
(advisory write) locks on it.

To me it seems that access rights should be completely independent of issues
of locking.  Either you have permission to read a given resource or you
don't.  The server can figure this out without knowing the lock state of the
resource.  Then it checks separately for the lock state to decide whether to
let you read the resource now.

We might need to look again at the types of locks we define.  I have seen
RDBMSs that distinguish between stronger and weaker types of write locks --
one that lets people read while the write lock is in place, and one that
does not.

--Judy
Name:			Judith A. Slein
E-Mail:			slein@wrc.xerox.com
Internal Phone:  	8*222-5169
External Phone:		(716) 422-5169
Fax:			(716) 265-7133
MailStop:		128-29E

Received on Thursday, 3 July 1997 09:54:17 UTC