- From: Judith Slein <slein@wrc.xerox.com>
- Date: Mon, 7 Jul 1997 07:10:05 PDT
- To: jradoff@novalink.com, w3c-dist-auth@w3.org
- Cc: Judith Slein <slein@wrc.xerox.com>
Yes, I think we need to have more discussion around locking / reservations / access control and how they all relate to each other. 1. The interpretation of "reservation" that seemed to prevail in this mailing list is that it is strictly informational. The presence of a reservation on a resource does not prevent anyone from reading or writing it -- it just lets others know that the reservation owner may be editing the resource. 2. I see how your requirement derives from Jim's suggestion that we may need to be able to prevent people from reading a resource while it has a write lock. I would like to suggest, however, that this has nothing to do with access control. It may turn out that access control and locks get implemented using the same techniques, but I think it's worth keeping the concepts separate at least through the requirements phase. Access rights are persistent properties of resources, whereas locks are short-lived states of resources. Locks and access rights interact in complex ways that will be difficult to capture if we treat them as a single thing. If we think it's desirable for write locks to prevent users from reading the resource, then that's just part of the definition of a write lock. If we think there need to be two flavors of write lock, one of which prevents users from reading the resource, one of which allows reading, that is possible, too. In either case, the lock is a separate consideration from access rights, and the server has to take both lock state and access rights into account in deciding whether to allow a given user to read the resource. --Judy At 08:52 AM 7/3/97 PDT, Jon Radoff wrote: >My idea may have more to do with "reservation" than the concept >of locking. > >The following was proposed by Jim 5-16-97: > > : I'd like to throw out for discussion a "minimalist" view of access > : control. My hypothesis is the only access control necessary in the > : client-server WebDAV protocol is a method which temporarily changes > : the access rights of a resource such that only (write) lock holders > : may read the resource, and another message which reverts the access > : rights back to their original form once editing is complete (or > : perhaps this happens automatically once all locks are released). This > : limited access control provides document privacy during editing, so > : authors are assured that others will not be reading their preliminary > : work. > >[See "Re: Access Control Draft" for 5-16-97 on the WebDAV mail archive] > >I don't really agree with the minimalist requirement for access >control, but I tried to extract the spirit of the concept into the >section on locking with access control. > >It seems logical that reservation (call it document privacy, >locking, or whatnot) should be managed by the access control >component. The reservation state of a document essentially >controls who is allowed to access it in a given way at a given >time. > >It seems like this area needs further comment... > >Jon > > 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 Monday, 7 July 1997 15:49:29 UTC