W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1998

RE: v6: 12.9 lockdiscovery

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Mon, 26 Jan 1998 12:15:16 -0800
Message-ID: <01BD2A54.10A7E520.ejw@ics.uci.edu>
To: "'Yaron Goland'" <yarong@microsoft.com>, "'Jim Davis'" <jdavis@parc.xerox.com>, "w3c-dist-auth@w3.org" <w3c-dist-auth@w3.org>
Cc: "Saveen Reddy (Exchange)" <saveenr@exchange.microsoft.com>
This sounds OK to me, with one addition.  I think that in the case where 
the underlying storage system has a non-WebDAV lock, the owner element 
should indicate this (e.g., by saying "repository lock" or somesuch).  This 
would give a person a minimal chance of figuring out what is going on. 
Without this, their chances are nil.

- Jim

On Saturday, January 24, 1998 4:49 PM, Yaron Goland 
[SMTP:yarong@microsoft.com] wrote:
> An excellent point. My guys brought up the exact same issue only 
> I would like to propose some language to deal with this issue:
> 1. All locks outstanding on a resource MUST be listed. To do otherwise 
> confuse the hell out of a client who is getting locked errors on PUTs but
> doesn't see any write locks listed in lockdiscovery.
> 2. Owner, timeout, and locktoken are to be made optional.
> One of the problems we have run into is that sometimes a resource gets
> locked through a mechanism other than DAV, for example a program directly
> manipulating the underlying operating system. While the DAV server will 
> about the lock, it will not have the ability to do anything with it. As 
> it doesn't have a "lock token" for the lock. We could, of course, just 
> a fake lock token. But the problem is that we expect, eventually, that
> administrative tools will be written to work with DAV. An administrator 
> tries to force an unlock using a fake lock token is in for a very 
> time. Additionally I also think that timeout should be optional because 
> information may not always be available. Finally, I don't think depth 
> be optional. I hate "default values" (in this case if Depth is not 
> its value is taken to be 0). They always lead to trouble.
> Currently the production for activelock is:
> <!ELEMENT activelock (locktype, lockscope, depth?, owner, timeout,
> locktoken) >
> Under the proposed changed it would become:
> <!ELEMENT activelock (locktype, lockscope, depth, owner?, timeout?,
> locktoken?) >
> Is this acceptable to everyone?
> 			Yaron
> PS Jim, as always, you're the man.
> > -----Original Message-----
> > From:	Jim Davis [SMTP:jdavis@parc.xerox.com]
> > Sent:	Saturday, January 24, 1998 2:04 PM
> > To:	w3c-dist-auth@w3.org
> > Subject:	v6: 12.9 lockdiscovery
> >
> > 12.9 says "The server is free to withhold any or all of this 
> > if
> > the requesting principal does not have sufficient access rights to see 
> > requested data."
> >
> > If the server does not wish to inform caller of, say, the owner, then
> > should it generate an empty owner or should it leave it out of the
> > activelock altogether?  The latter would violate the syntax of 
> > as only depth is optional.  I am not sure whether all the other 
> > of
> > activelock are defined to allow them to be empty.  If any of them are,
> > then
> > we have an inconsistency.  If all of them allow empty, then the spec
> > should
> > add language telling what to do.
Received on Monday, 26 January 1998 15:44:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:12 UTC