Yes, I think that makes sense.

On Apr 28, 2004, at 2:36 PM, Julian Reschke wrote:

> 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 -- -- tel:+492512807760

Received on Wednesday, 28 April 2004 17:44:10 UTC