Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS

Lisa Dusseault wrote:

> So far we've only considered lock "stealing" for the purpose of 
> destroying a lock (e.g. if somebody locked a file and went on 
> vacation).  If I steal somebody else's lock to use it and change the 
> file while still leaving it under the same lock there *will* be 
> interoperability problems because there's no way to coordinate.
> 
> Going from that limited UNLOCK use case to a more general content 
> management use case, where multiple people might use the locked resource 
> is a big step and we don't have a lot of experience (that I know of).  
> Recall that shared locks were invented for the latter case, not 
> exclusive lock token sharing.

I c. I absolutely agree that using somebody else's lock token to get rid 
of the lock (did the other forget to unlock before leaving for the 
weekend?) is a completely different use case then *using* the lock token 
in methods other than UNLOCK (that is, in the "If" header). *That* is 
something we may want to clarify.

That still leaves the use case of a public resource that supports locks. 
I think this is allowed today, and actually is in use. We should not 
forbid that.

So maybe we should close the two issues mentioned, and add a new one 
specifically for this question?

 From my point of view:

- There are no restrictions on who a server allows to UNLOCK using a 
"stolen" lock token. It MAY restrict it to the "owner" of the lock, to 
the owner and principals holding the DAV:unlock privilege, or not 
restrict it at all. In particular, there's no requirement that for each 
lock token there actually *is* an "authenticated owner" (unless you 
count the ACL specs's "DAV:unauthenticated").

- On the other hand, submitting the lock token in an If header (usages 
!= UNLOCK) SHOULD be restricted to whatever the server thinks the 
"owner" of the lock is.

Does this make sense?

Regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Wednesday, 28 April 2004 17:37:45 UTC