W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1999

Re: DELETE leaving a lock-null resource; was LOCK Scenarios

From: Edgar Schwarz <Edgar.Schwarz@de.bosch.com>
Date: Fri, 24 Sep 1999 13:01:18 +0200
Message-ID: <37EB59FE.8785C4AF@de.bosch.com>
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 GMT

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