RE: v6: 12.9 lockdiscovery

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 
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 Monday, 26 January 1998 15:44:24 UTC