Re: resolving 057_LOCK_SEMANTICS

This is all fine with me, except I'd like to delete the "MAY"
clause from the last sentence in the update to (c).
Weakening this to a SHOULD is as far as we should go.
Explicitly adding in the MAY sentence looks too much like
encouragement to do the wrong thing.

Cheers,
Geoff

Julian wrote on 06/17/2004 01:53:21 PM:

> 
> Hi,
> 
> I have resolved 057_LOCK_SEMANTICS in 
> 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html> 

> with the following changes (see previous mailing list discussion in 
> 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/thread.html#57
> >):
> 
> 
> a) Define a generic precondition:
> 
> "(DAV:lock-submission-allowed): If the server restricts usage of the 
> lock token inside an "If" request header to specific principals, the 
> authenticated principal for this request MUST be one of them."
> 
> 
> b) Change UNLOCK precondition DAV:lock-owner-matches to:
> 
> "(DAV:lock-removal-allowed): As dicussed above, the principal 
> authenticated for the UNLOCK request MUST be allowed to remove the 
> identified lock (note that servers that support the "WebDAV Access 
> Control Protocol" should use the DAV:need-privileges precondition 
> defined in section 7.1.1 of [RFC3744])."
> 
> 
> c) Update "Write Locks and the If Request Header" as follows:
> 
> OLD:
>     "In order to prevent these collisions a lock token MUST be submitted 

> by an authorized principal in the If header for all locked resources 
> that a method may interact with or the method MUST fail. For example, if 

> a resource is to be moved and both the source and destination are locked 

> then two lock tokens must be submitted, one for the source and the other 

> for the destination."
> 
> NEW:
>     "In order to prevent these collisions a lock token MUST be submitted 

> in the If header for all locked resources that a method may interact 
> with or the method MUST fail. For example, if a resource is to be moved 
> and both the source and destination are locked then two lock tokens must 

> be submitted, one for the source and the other for the destination.
> 
> Servers SHOULD 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."
> 
> 
> Best regards, Julian
> 
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>