Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS

Lisa Dusseault wrote:

> [...] we need more discussion and for people to indicate which side 
> they fall on.
> 1. Authentication is required for lock token usage but the draft is 
> clear enough already.
> 2. Authentication is required for lock token usage but the draft needs 
> clearer text (please suggest where, what text).
> 3. Authentication MAY be required for lock token usage (see text below).
> 4. Other -- please describe your position.

I've always believed that authentication and lock token usage were 
orthogonal. To add to Julians' example of anonymous authoring of 
resources involving lock tokens, I'd add the following use case. Given a 
locked resource, R, and two principals, P1 and P2, with different access 
priviledges such that P1 can PUT to R, but P2 can only do a PROPPATCH to 
R. This scenario may arise in a content management system where resource 
properties are used to indicate the current state of the resource. It 
seems clear to me from this scenario that the issues of authentication 
(whether by user, group or method) and lock token usage are decoupled.

> [...] Here's some proposed text to consider adding to section 7.6 if 
> we lean towards option 3 above (note this would also require changing 
> the text in the above quoted paragraphs):
>
> 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. 

I agree with the above proposed text, however it may lead to some 
interoperability issues. Is there a proposed mechanism to allow clients 
to discover how a server handles the intersection of these design choices?


Cheers,
Elias