RE: v6: 12.9 lockdiscovery

This text doesn't deal with the scenario where program A takes out a lock, the disk gets trashed and the system crashes, and the user wishes to perform an operation on the locked resource from another machine or after restoration of a backup made before the lock was granted.

It also doesn't deal with a situation where the user takes a lock out with program A and wishes to manipulate the resource with program B (after a dialogue asking the user whether the operation should be performed even though the lock was taken-out by another system).

We need to guarantee that the user can do this withour administrator interference.

Cheers
Dylan

-----Original Message-----
From:	Yaron Goland [SMTP:yarong@microsoft.com]
Sent:	Thursday, January 29, 1998 11:17 PM
To:	'Dylan Barrell'; 'Jim Davis'; w3c-dist-auth@w3.org
Cc:	Saveen Reddy (Exchange)
Subject:	RE: v6: 12.9 lockdiscovery

Please refer to section 5.7 of the 05 draft for an entire section dedicated
to explaining the very principal you mention and section 5.6 for a
particular example. I will change the order of these two sections in the
next version of the draft because of the reverse dependency.

	Yaron

> -----Original Message-----
> From:	Dylan Barrell [SMTP:dbarrell@opentext.ch]
> Sent:	Thursday, January 29, 1998 12:54 PM
> To:	Yaron Goland; 'Jim Davis'; w3c-dist-auth@w3.org
> Cc:	Saveen Reddy (Exchange)
> Subject:	RE: v6: 12.9 lockdiscovery
> 
> This might seem obvious but I think it should be stated that the locktoken
> MUST be returned if the requesting principle is the owner of the lock
> (seeing as we don't go into permissions in any further detail, we must
> guarantee that the owner of a lock can always retrieve the token).
> 
> Cheers
> Dylan
> 
> 
> -----Original Message-----
> From:	Yaron Goland [SMTP:yarong@microsoft.com]
> Sent:	Sunday, January 25, 1998 1:49 AM
> To:	'Jim Davis'; w3c-dist-auth@w3.org
> Cc:	Saveen Reddy (Exchange)
> Subject:	RE: v6: 12.9 lockdiscovery
> 
> An excellent point. My guys brought up the exact same issue only
> yesterday.
> 
> 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
> would
> 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
> know
> about the lock, it will not have the ability to do anything with it. As
> such
> it doesn't have a "lock token" for the lock. We could, of course, just
> issue
> a fake lock token. But the problem is that we expect, eventually, that
> administrative tools will be written to work with DAV. An administrator
> who
> tries to force an unlock using a fake lock token is in for a very
> confusing
> time. Additionally I also think that timeout should be optional because
> the
> information may not always be available. Finally, I don't think depth
> should
> be optional. I hate "default values" (in this case if Depth is not present
> 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 information
> > if
> > the requesting principal does not have sufficient access rights to see
> the
> > 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
> activelock,
> > as only depth is optional.  I am not sure whether all the other elements
> > 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 Sunday, 1 February 1998 08:32:13 UTC