RE: v6: 12.9 lockdiscovery

Dylan, we provide a very specific example for why we believe that lock
tokens are absolutely required. If you would please address that example and
explain why it is that example is wrong you would go a long way toward
helping convince others of your view.

As for your concerns regarding servers, I am remiss to overly constrain
servers. A good standard allows people to do the right thing but no standard
can prevent them from doing the wrong thing. Furthermore I personally
dislike "motherhood and apple pie" requirements. I believe that a
requirement along the lines of "A server SHOULD allow the owner of a lock
token to see the lockdiscovery property containing that lock." is so self
evident that it can only be considered content free.

Furthermore I would like to understand how you feel that the current
language, from section 12.8 is insufficient.

			Yaron

> -----Original Message-----
> From:	Dylan Barrell [SMTP:dbarrell@opentext.ch]
> Sent:	Tuesday, February 03, 1998 1:36 AM
> To:	Yaron Goland; 'Jim Davis'; w3c-dist-auth@w3.org
> Cc:	Saveen Reddy (Exchange)
> Subject:	RE: v6: 12.9 lockdiscovery
> 
> The problem I have with the spec is that it talks about permissions and
> withholding information based on permissions but doesn't go into any more
> detail about the permissions and/or which information is mandatory for
> different classes of user. In the case of locks there are two classes of
> users - those that own a lock and those that do not. In order to avoid
> braindead server implementations we should explicitly state which
> information the "owner of a lock" class of users is entitled to
> (regardless of other permissions) - one of these is the lock token.
> 
> The argument in favour of having a lock token in the first place is very
> weak because from a user perspective if a user uses locks, has taken-out a
> lock with one application and then performs a PUT on the locked resource
> from another application, it is VERY likely that she knows what she is
> doing. I think that the lock token introduces unnecessary balast to the
> spec for very little benefit (especially considering the fact that the
> implementors have to become familiar with and support the opaque lock
> token specification). I would like lock tokens to be optional (server
> decision) or removed from the spec entirely.
> 
> Other comments below
> 
> Cheers
> Dylan
> 
> -----Original Message-----
> From:	Yaron Goland [SMTP:yarong@microsoft.com]
> Sent:	Sunday, February 01, 1998 9:01 PM
> To:	'Dylan Barrell'; 'Jim Davis'; w3c-dist-auth@w3.org
> Cc:	Saveen Reddy (Exchange)
> Subject:	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.
> [Dylan Barrell]  The lock is not gone if the user's client machine
> crashed. In this case the user must be guaranteed to be able to retrieve
> the lock token.
> 
>  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.
> [Dylan Barrell]  This must be guaranteed to be provided.
> 
> 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 Tuesday, 3 February 1998 14:27:25 UTC