- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Mon, 21 Oct 2002 16:31:29 +0200
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "Clemm, Geoff" <gclemm@rational.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
The conformant behaviour would be to disallow DELETE on "the" uri of a version/version history unless the uri is already the last bindung to the resource. This would avoid the requirement that *all other* binding must be removed which is exactly the opposite of what the binding spec (currently) says. //Stefan Am Montag, 21.10.02, um 16:20 Uhr (Europe/Berlin) schrieb Julian Reschke: > >> From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On >> Behalf Of Clemm, Geoff >> Sent: Monday, October 21, 2002 3:32 PM >> To: 'Webdav WG' >> Subject: RE: BIND vs. non-movable resources in RFC3253 >> >> >> I believe the answer should be (c). >> The original binding to a version or a version >> history has special semantics (i.e. if you >> delete it, the resource is destroyed, and all bindings >> to it are destroyed), while additional bindings (such >> as those in a working collection) just have normal DELETE >> semantics, i.e. just that binding is deleted. >> So MOVE would not be allowed on the original binding, >> but is allowed on any other bindings. >> And yes, once the BIND protocol is standardized, the >> next revision of the DeltaV protocol should add the appropriate >> preconditions to handle BIND semantics. > > I really have a problem with this approach. The BIND spec just > clarified > DELETE to mean: > > "The DELETE method requests that the server remove the binding between > the > resource identified by the Request-URI and the binding name, the last > path > segment of the Request-URI. The binding MUST be removed from its parent > collection, identified by the Request-URI minus its trailing slash (if > present) and final segment. > > Once a resource is unreachable by any URI mapping, the server MAY > reclaim > system resources associated with that resource. If DELETE removes a > binding > to a resource, but there remain URI mappings to that resource, the > server > MUST NOT reclaim system resources associated with the resource." > > You seem to say that other specs are allowed to override this > definition. In > which case I'd claim that the model that the BIND spec tries to > establish > isn't correct, and that we shouldn't attempt to establish this > definition > for deletes of bindings. > > IMHO, > > - up until now, specs usually defined DELETE as *both* removing the URI > mapping and the destruction of resources, > > - the BIND spec changes this view so that the resource MAY be > destroyed when > the last binding disappears, > > - therefore, DELETE behaviour defined in old specs should now be > understood > as definining what may occur when the last binding disappears. > > In this particular case, I'd like to understand why we actually want to > forbid MOVE on versions and version histories. I understand that once > a URI > has been allocated for a version or a VHR, it should never identity > anything > else. So the defined contract basically guarantees that upon > GET/PROPFIND on > this URI, I will either > > - access the very same resource or > - that I'll get a 404. > > I don't think that we need the special MOVE conditions to guarantee > this. > From a client's point of view, it's irrelevant whether the resource is > gone > or is now "somewhere else" (yes, servers may want to forbid the MOVE > for > other reasons). > > Julian > >
Received on Monday, 21 October 2002 10:32:12 UTC