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 Saturday, 24 January 1998 19:49:25 UTC