Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS

But how can clients discover if servers allow any authenticated user 
(other than the one that got the lock)?  Without servers advertising 
this toggle, it seems very unlikely that clients will use it as they 
cannot rely on it.  Unless of course the client is talking to a server 
by the same vendor in which case there may be other non-standard 
behaviors that the standard has no business describing.

So yeah, it might be desirable but it's not a slam dunk.

lisa

On Apr 28, 2004, at 1:15 PM, Elias Sinderson wrote:

> 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

Received on Wednesday, 28 April 2004 16:56:44 UTC