Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS

Julian, just so I make sure there's a clear consensus, was the proposed 
text OK?

>>
>> Servers MAY restrict usage of the lock token to exactly the
>> authenticated principal who created the lock. Servers MAY also allow
>> other privileged authenticated principals or even unauthenticated
>> principals to use the lock token.

It was my sense that Geoff, Jason and Elias were more or less on board 
with this but I was confused by your latest reply.

Elias suggested explaining how clients discover how a server handles 
these design choices, but this mostly codifies how things already work 
today and we seem to have pretty successful interoperability in this 
area.  As it stands today, if the server requires authentication and 
the client didn't provide it, the server responds with a 403 and 
clients deal with that appropriately.

Did anybody have any alterations to suggest to this text?

Lisa

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 -- http://www.greenbytes.de -- tel:+492512807760
>

Received on Monday, 3 May 2004 12:51:11 UTC