- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 04 Apr 2007 17:49:08 +0200
- To: Tim Olsen <tolsen718@gmail.com>
- CC: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, w3c-dist-auth@w3.org
Tim Olsen schrieb: > On 3/29/07, Julian Reschke <julian.reschke@gmx.de> wrote: >> Tim: speaking of which, was there anything in >> draft-ietf-webdav-rfc2518bis-18 >> (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-18.html>) >> or draft-ietf-webdav-bind-18 >> (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-18.html>) >> suggesting something else? > > Somewhat. The very beginning of section 9.9 of 2518bis says > "The MOVE operation on a non-collection resource is the logical > equivalent of a copy (COPY), followed by consistency maintenance > processing, followed by a delete of the source, where all three > actions are performed in a single operation" > > which might imply that one does not require the locktoken. True. That statement is incorrect with respect to locking (as a COPY with Overwrite: T may just be updating an existing resource, while a MOVE will remove the binding and thus affect the parent collection): > But the bind draft is pretty clear that REBIND and BIND require the > locktoken. This would imply that if I implemented MOVE using REBIND, > then MOVE would require the locktoken. > > I think that's how I got confused. > > Thanks for the clarification. > > Cheers, > Tim I would say no matter how you implement it, the lock token needs to be submitted. You are changing the state of the locked collection. It's really unfortunate that the locking section of RFC2518bis hasn't fully adopted the very clear semantics we collaborated on, see <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/1003.html>). Best regards, Julian
Received on Wednesday, 4 April 2007 15:49:42 UTC