- From: Edgar Schwarz <Edgar.Schwarz@de.bosch.com>
- Date: Fri, 24 Sep 1999 13:01:18 +0200
- To: w3c-dist-auth@w3.org
Geoffrey M. Clemm wrote: > <gmc/> But I have seen various arguments in the past that a LOCK should > also protect the URL to resource mapping. For my part I was just concerned that the locker should be able to find his locked resource after a MOVE. > to resource mapping, I'd propose that a locked resource be allowed to > MOVE (this is just a change to the state of the parent collection, not > to the state of the resource being moved), but that an attempt to > access the MOVE'd resource with that lock just returns a 302 indicating > where it has MOVE'd to. This would give me what I wanted. I even could imagine that it is enough that only a access with the lock token MUST get the new location. For all others it's just gone, like other resources which are moved. So a server could just remember lock tokens together with old and new URLs and keep this data until it is accessed by the locker or the lock expires. > <gmc/> So there are really multiple threads here: > - Should locking be on a resource or also/instead on a URL-to-resource > mapping? (we know what it is now, but what *should* it be) > * I vote "on a resource". > - Does a DELETE delete all bindings to a resource, or just the one > specified in the request-URL. > * I vote "just the one named by the request-URL". > - Should a DELETE delete a LOCK? > * I vote, "no". A DELETE modifies the state of the collection containing > the binding, not that of the resource. In particular, all other > mappings to that resource will continue to exist and display the > LOCK'ed semantics. If you want to prevent a DELETE, you put the > LOCK on the collection whose state is being modified. Agreement on all points. The last couple of days I thought that already too much energy was spent with this topic. This proposal seems to be as simple as possible, but not simpler. Regards, Edgar -- Edgar.Schwarz@de.bosch.com ON/EUE1, 07191/13-3382 Niklaus Wirth: Privat kann jeder soviel C programmieren oder Videos ansehen wie er mag. Albert Einstein: Mach es so einfach wie moeglich, aber nicht einfacher.
Received on Friday, 24 September 1999 07:02:17 UTC