- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 05 Apr 2004 21:30:34 +0200
- To: Patrik Fältström <paf@cisco.com>
- Cc: w3c-dist-auth@w3.org
Patrik Fältström wrote: > ... > It seems Julian is talking about locking always being on the resource, > regardless of what binding was used. This imply it is completely > irrelevant what binding has happend, what URI is used etc to reach the > resource. If the resource is locked it is. > ... Correct. IMHO this follows clearly from RFC2518 (specifically the introduction of locking (section 6) and write locks (section 7))...: "The ability to lock a resource provides a mechanism for serializing access to that resource. Using a lock, an authoring client can provide a reasonable guarantee that another principal will not modify a resource while it is being edited. In this way, a client can prevent the "lost update" problem." "A write lock MUST prevent a principal without the lock from successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, DELETE, or MKCOL on the locked resource. All other current methods, GET in particular, function independently of the lock." BTW: at some point in the previous discussions it was claimed that RFC2518 uses the terms "URI" and "resource" interchangeably, and thus there was no explicit distinction. I disagree with that point of view. If there are places where RFC2518 is sloppy in this regard, we should identify those and try to fix them in RFC2518bis. Regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Monday, 5 April 2004 15:38:13 UTC