RE: v6: 12.9 lockdiscovery

Let us examine your scenarios.

1) User A locked the resource but the system crashed and came back on-line,
however his lock is now gone. Assuming user A doesn't know about the crash
he tries his operation and includes a lock-token header. The operation
succeeds because the resource isn't locked so therefore the lock-token
header is ignored. User A may wish to be able to say something like "Don't
perform this operation UNLESS the resource is locked". In that case the user
can put an if-state-match header on the request with the lock token. Since
that token no longer identifies the state of the resource because the
resource isn't locked, the request will fail, as the user wanted. In neither
case, however, is an administrator required.

2) Section 5.7 defines that same scenario and section 8.7, which is directly
referenced from within 5.7, then solves it. To summarize what is said there,
program B would try the operation and get back a Locked error. Program B can
then perform lock discovery to determine if their user is one of the lock
owners, if so, the program can then get the lock token from lock discovery
and pop up a dialog asking the user if they wish to perform the operation
using the retrieved token. Again, no administrator required.

BTW I reviewed the text and realized that we don't ever explicitly say that
"If a resource is not locked then the lock-token header MUST be ignored on
that resource." The reason for this behavior is that we expect, in the
future, that there will be additional state tokens for different sorts of
states. One such token has already been introduced, for transactioning
[ftp://ietf.org/internet-drafts/draft-ietf-tip-usehttp-00.txt - BTW I just
sent in a new version so the URL might change to
ftp://ietf.org/internet-drafts/draft-ietf-tip-usehttp-01.txt]. If the
lock-token header caused a failure on an unlocked resource then it would
become impossible to say things like "Don't perform this action unless the
resource is either locked or transactioned." To solve such problems we
introduced the if-[none-]state-match headers defined in sections 8.5 and
8.6.

Oh and the reason to have a total separate lock-token header is so as to be
able to say to the resource "Look, if the resource is locked, here is my
lock-token, but if it isn't, I don't care, perform the operation anyway."
	
	Yaron

PS Dylan, section 8.7 already contains the exact wording you asked for in
your original post in this thread.


> -----Original Message-----
> From:	Dylan Barrell [SMTP:dbarrell@opentext.ch]
> Sent:	Friday, January 30, 1998 1:37 PM
> To:	Yaron Goland; 'Jim Davis'; w3c-dist-auth@w3.org
> Cc:	Saveen Reddy (Exchange)
> Subject:	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 15:01:49 UTC