W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2004

resolving 057_LOCK_SEMANTICS

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 17 Jun 2004 19:53:21 +0200
Message-ID: <40D1DA91.2050907@gmx.de>
To: w3c-dist-auth@w3.org

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
Received on Thursday, 17 June 2004 13:53:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT